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Abstract 


Organizations  using  the  Capability  Maturity  Model  for  Software  (SW-CMM  )  to  guide  their 
software  process  improvement  efforts  often  struggle  with  implementation  details.  The  Team 
Software  Process™  (TSPsm)  was  designed  to  implement  effective,  high-maturity  processes 
for  project  teams.  The  TSP  contains  a  framework  as  well  as  a  set  of  processes,  procedures, 
guidelines,  and  tools  for  project  teams  to  use  in  the  production  of  high-quality  software  on 
time  and  on  budget. 

Since  the  SW-CMM  describes  what  an  organization  at  a  high  level  of  process  maturity  should 
be  doing,  and  the  TSP  describes  how  high-maturity  processes  are  implemented  for  project 
teams,  the  question  arises:  If  all  projects  in  an  organization  were  using  the  TSP,  would  the 
organization  exhibit  the  characteristics  of  high  process  maturity,  as  described  in  the  SW- 
CMM?  To  help  answer  this  question,  we  performed  an  analysis  of  the  degree  to  which  the 
SW-CMM  is  addressed  by  the  TSP.  Each  key  practice  described  in  the  SW-CMM  was  classi¬ 
fied  as  having  an  organizational  or  project  scope,  or  both.  Then  each  practice  was  examined 
to  determine  how  it  was  addressed  by  the  TSP.  The  results  presented  in  this  report  show  that 
the  TSP  implements  a  majority  of  the  key  practices  of  the  SW-CMM. 


®  Capability  Maturity  Model  and  CMM  are  registered  in  the  U.S.  Patent  and  Trademark  Office. 
SM  Team  Software  Process  and  TSP  are  service  marks  of  Carnegie  Mellon  University. 
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1  Introduction 


The  Capability  Maturity  Model®  for  Software  (SW-CMM®)  is  an  improvement  framework 
that  describes  the  key  elements  of  an  effective  organizational  software  process.  The  SW- 
CMM  describes  an  evolutionary  improvement  path  from  an  ad  hoc,  immature  process  to  a 
mature,  disciplined  process  [Paulk  95].  It  is  a  descriptive  model  because  it  describes  the  char¬ 
acteristics  of  an  organization  at  a  particular  maturity  level,  and  its  capabilities  for  quality, 
cost,  and  schedule  predictability.  The  results  achieved  from  CMM-based  process  improve¬ 
ment  are  impressive  [Herbsleb  94,  Lawlis  95],  but  many  organizations  struggle  to  define  and 
implement  operational  processes  for  the  key  practices  described  in  the  SW-CMM. 

The  Team  Software  ProcessSM  (TSPsm)  is  prescriptive,  defining  a  whole  product  framework 
of  customizable  processes  and  an  introduction  strategy  that  includes  building  management 
sponsorship,  training  for  managers  and  engineers,  automated  tool  support,  coaching,  and 
mentoring.  The  TSP  is  a  high-maturity  process  for  project  teams.  It  contains  an  adaptable  set 
of  processes,  procedures,  guidelines,  and  tools  for  project  teams  to  use  in  the  production  of 
high-quality  software  on  time  and  on  budget.  A  prerequisite  for  the  TSP  is  the  Personal  Soft¬ 
ware  ProcessSM  (PSPSM),  which  is  a  high-maturity  process  for  individual  software  engineers. 
In  terms  of  product  quality  and  schedule  variance,  the  results  from  the  use  of  the  PSP  and  the 
TSP  show  individuals  and  teams  producing  software  that  is  at  least  what  one  would  expect 
from  a  maturity  level  5  organization  [Ferguson  99,  Hayes  97,  McAndrews  00]. 


The  SW-CMM  and  the  TSP  are  complementary  by  design  [Humphrey  98a,  98b,  98c].  After 
guiding  the  development  of  the  SW-CMM,  Watts  Humphrey  went  on  to  develop  the  PSP  and 
TSP  to  apply  CMM  principles  at  the  individual  and  team  levels,  while  addressing  common 
shortcomings  in  implementing  the  SW-CMM  and  going  beyond  the  SW-CMM  to  more  spe¬ 
cifically  address  the  work  of  the  engineers  [Humphrey  02].  The  SW-CMM  describes  what  an 
organization  at  a  particular  maturity  level  should  be  doing,  while  the  TSP  prescribes  how 
high-maturity  practices  can  be  used  at  the  team  level.  Since  the  TSP  concentrates  on  project 
issues,  it  does  not  address  the  broader  organizational  aspects  of  any  CMM  level.  This  techni¬ 
cal  report  explores  the  common  elements  between  the  TSP  and  the  Capability  Maturity 
Model  for  Software  V.  1.1.  It  does  not  discuss  TSP  practices  that  have  no  corresponding 
CMM  practice. 


®  Capability  Maturity  Model  and  CMM  are  registered  in  the  U.S.  Patent  and  Trademark  Office. 

SM  Team  Software  Process,  TSP,  Personal  Software  Process,  and  PSP  are  service  marks  of  Carnegie 
Mellon  University. 
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The  purpose  of  this  document  is  to  describe  how  the  TSP  addresses  each  key  process  area 
(KPA)  of  the  SW-CMM  and  to  record  observations  about  how  the  TSP  addresses  each  key 
practice  in  the  SW-CMM.  These  observations  can  serve  as  one  set  of  inputs  in  determining 
how  to  use  the  TSP  to  implement  and  accelerate  CMM-based  software  process  improvement. 


The  primary  audience  for  this  report  includes  the  following: 

•  organizations  currently  using  the  TSP  who  want  to  incorporate  the  additional  organiza¬ 
tional  practices  described  in  the  SW-CMM 

•  organizations  that  have  decided  to  adopt  CMM-based  software  process  improvement  and 
are  looking  for  processes  that  implement  the  SW-CMM 

•  organizations  that  have  started  implementing  the  SW-CMM  and  are  interested  in  high- 
maturity  team  practices 


A  secondary  audience  for  this  report  includes  the  following: 

•  individuals  who  are  interested  in  software  process  improvement 

•  CMM-Based  Appraisal  for  Internal  Process  Improvement  (CBA IPI)  Lead  Assessors 

•  PSP  instructors  and  TSP  launch  coaches 

Familiarity  with  either  the  SW-CMM  or  TSP,  and  some  understanding  of  the  other,  would  be 
helpful  in  understanding  this  report.  Several  articles  and  textbooks  describe  the  TSP  and  the 
SW-CMM.  Overview  information  on  the  SW-CMM  is  available  on  the  Software  Engineering 
Institute  Web  site:  http://www.sei.cmu.edu/cmm.  Articles  and  papers  on  the  SW-CMM  are 
also  available  at  http://www.sei.cmu.edu/cmm/cmm.articles.html.  Information  about  the  TSP 
is  available  on  the  SEI  Web  site  at  http://www.sei.cmu.edu/tsp. 
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2  Methodology 


In  relating  the  TSP  and  the  SW-CMM,  the  first  step  was  to  define  the  fundamental  concepts 
of  “organization”  and  “project”  in  context  of  the  TSP.  The  terms  “organization”  and  “project” 
have  specific  meaning  in  the  SW-CMM.  An  organization  is  defined  as  “a  unit  within  a  com¬ 
pany  or  other  entity  (e.g.,  a  government  agency  or  branch  of  service)  within  which  many  pro¬ 
jects  are  managed  as  a  whole.  All  projects  within  an  organization  share  a  common  top-level 
manager  and  common  policies.”  A  project  is  defined  as  “an  undertaking  requiring  concerted 
effort,  which  is  focused  on  developing  and/or  maintaining  a  specific  product.  The  product 
may  include  hardware,  software,  and  other  components.  Typically  a  project  has  its  own  fund¬ 
ing,  cost  accounting,  and  delivery  schedule”  [Paulk  95]. 


A  project,  as  defined  by  the  SW-CMM,  could  be  composed  of  more  than  one  TSP  team.  The 
TSP  process  guides  projects  executed  by  single  teams.  An  extended  version  of  the  TSP  guides 
projects  executed  by  multiple  teams.  Teams  can  be  software-only  TSP  teams,  multi¬ 
disciplinary  TSP  teams,  or  a  mix  of  team  types  in  the  case  of  multiple-team  projects.  This 
report  adopts  the  SW-CMM  definition  of  project  and  organization,  with  the  following  as¬ 
sumptions: 

•  The  organization  is  following  the  standard  SEI  TSP  introduction  strategy,  as  described  in 
Section  8.1. 

•  The  organization  has  moved  beyond  TSP  pilots  to  widespread  use  of  the  TSP. 

•  Projects  use  the  TSP  as  early  as  possible  in  the  project  life  cycle. 

•  Projects  use  multi-disciplinary  TSP  teams  and/or  the  multiple-team  version  of  the  TSP  as 
necessary. 

The  next  step  after  documenting  the  definitions  and  assumptions  was  to  resolve  the  differ¬ 
ences  in  scope  of  the  TSP  and  the  SW-CMM.  The  intent  of  the  SW-CMM  is  for  some  key 
practices  of  the  SW-CMM  to  be  addressed  at  the  organizational  level,  some  at  the  project 
level,  and  some  at  both  levels.  The  TSP  mostly  addresses  process  improvement  at  the  project 
and  individual  levels.  To  resolve  this,  each  key  practice  of  the  SW-CMM  was  examined  to 
determine  at  what  level  of  the  organization,  project  level  or  organization  level,  the  SW-CMM 
intended  the  key  practice  to  be  addressed.  Each  key  practice  was  classified  as  being  ad¬ 
dressed  at  the  organization  level,  at  the  project  level,  or  at  both  the  organization  and  project 
levels.  The  detailed  methodology  and  the  resulting  classification  of  key  practices  are  pre¬ 
sented  in  Section  9  of  this  report. 
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Next,  observations  were  recorded  for  each  key  practice  of  the  SW-CMM  by  citing  specific 
TSP  documents:  a  process  script,  a  form,  a  specification,  a  guideline,  or  a  combination.  Ob¬ 
servations  take  the  form  of  a  direct  quote  or  paraphrase  of  the  text  being  referenced,  a  synop¬ 
sis  of  a  larger  piece  of  a  document,  or  a  summary  of  the  collective  intent  of  a  set  of  process 
elements.  Observations  also  record  the  degree  to  which  the  key  practice  is  addressed  by  the 
TSP  at  the  project  level  and  at  the  organization  level  according  to  the  following  rules: 

•  A  key  practice  is  “not  applicable”  at  the  project  level  if  the  intent  of  the  SW-CMM  is  for 
that  key  practice  to  be  addressed  mainly  at  the  organization  level. 

•  A  key  practice  is  “not  applicable”  at  the  organization  level  if  the  intent  of  the  SW-CMM 
is  for  that  key  practice  to  be  addressed  mainly  at  the  project  level. 

•  A  key  practice  is  “fully  addressed”  if  the  TSP  satisfies  the  intent  of  that  key  practice. 

•  A  key  practice  is  “not  addressed”  if  the  intent  is  not  satisfied. 

•  A  key  practice  is  “partially  addressed”  if  the  degree  of  satisfaction  is  anywhere  between 
fully  addressed  and  not  addressed. 

The  detailed  methodology  and  the  resulting  observations  are  presented  in  Section  8. 

It  is  important  to  understand  the  context  in  which  these  observations  were  recorded.  Observa¬ 
tions  were  recorded  for  static  descriptions  of  the  SW-CMM  and  the  TSP  in  light  of  the  as¬ 
sumptions  listed  above.  Processes  used  by  organizations  and  projects  to  actually  perform 
their  work  are  dynamic  instantiations  of  the  process  descriptions  examined  in  this  paper.  It  is 
the  dynamic  execution  of  these  processes  that  will  show  whether  the  use  of  the  TSP  indeed 
addresses  the  goals  of  various  KPAs  of  the  SW-CMM. 

For  readers  not  interested  in  the  details  presented  in  Sections  8  and  9,  summary  information 
about  the  relationship  between  the  TSP  and  the  SW-CMM  at  each  process  maturity  level  is 
presented  in  Sections  3, 4,  5,  and  6. 
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3  TSP  and  Level  2 


The  focus  of  maturity  level  2  is  on  management  processes.  Requirements  are  managed  to  en¬ 
sure  understanding  customer  commitments,  projects  are  planned  and  tracked  to  ensure  meet¬ 
ing  schedule  commitments,  and  subcontracts  are  managed  to  ensure  subcontractors  meet  their 
commitments.  Software  Quality  Assurance  (SQA)  provides  management  with  visibility  into 
the  processes  and  procedures  being  used  by  projects  to  meet  their  commitments.  Software 
Configuration  Management  (SCM)  ensures  the  integrity  of  the  work  products  being  pro¬ 
duced. 

At  level  2,  the  TSP  provides  specific  guidance  for  Software  Project  Planning  (SPP),  Software 
Project  Tracking  and  Oversight  (SPTO),  Requirements  Management  (RM),  and  SQA.  The 
activities  constituting  effective  SCM  are  mainly  enabled  and  encouraged.  Software  Subcon¬ 
tract  Management  (SSM)  is  outside  the  scope  of  the  TSP,  and  is  not  explicitly  addressed,  but 
it  is  not  unusual  for  an  organization  using  the  TSP  to  start  asking  their  subcontractors  for 
TSP-equi valent  project  planning,  tracking,  and  quality. 


Figure  1  shows  the  percentage  of  project  key  practices  addressed  by  the  TSP  for  each  KPA  of 
level  2.  For  detailed  observations  on  each  key  practice,  see  Section  8. 


SPP  SPTO  SQA  SCM 


Key  Process  Areas 


Figure  1:  Project  Key  Practices  Profile  at  Level  2 
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4  TSP  and  Level  3 


Level  3  builds  on  level  2  in  several  ways.  At  level  2,  individual  projects  in  an  organization 
could  be  practicing  different  management  and  engineering  processes.  At  level  3,  the  projects 
are  expected  to  tailor  a  common  set  of  documented  and  approved  organization-wide  man¬ 
agement  and  engineering  processes.  Level  3  also  focuses  on  the  software  engineering  group 
by  addressing  engineering  processes  and  on  the  need  for  the  software  engineering  group  to  be 
involved  with  other  engineering  groups.  As  projects  start  using  a  common  set  of  management 
and  engineering  processes,  these  processes  can  be  more  effectively  instrumented.  Thus,  an 
organization’s  software  process  database  is  established  at  level  3  to  collect  data  on  the  soft¬ 
ware  processes  and  products.  Finally,  level  3  establishes  an  organizational  training  program, 
as  well  as  a  peer  review  process. 

Although  the  TSP  focus  is  on  teams  and  not  on  organizations,  it  supports  the  principal  intent 
of  level  3:  projects  in  the  organization  use  a  common  set  of  processes  to  perform  software 
development  and  maintenance  work,  and  projects  share  process  data  and  lessons  learned. 
Even  if  all  teams  in  an  organization  were  using  the  TSP,  there  is  the  need  for  additional  or¬ 
ganizational  support.  An  example  of  the  need  for  organizational  support  beyond  the  TSP  is 
evident  in  the  Organization  Process  Definition  (OPD)  KPA.  TSP  teams  collect  and  analyze 
product  and  process  data.  There  is  the  additional  need  for  an  organizational  function  that  col¬ 
lects,  reviews,  and  makes  this  data  available  for  use  across  the  organization,  as  needed. 

At  level  3,  the  TSP  provides  support  for  the  Organization  Process  Focus  (OPF)  and  OPD 
KPAs  by  improving  organizational  software  process  capability  and  by  providing  process 
elements,  process  architecture,  and  process  and  product  data  to  the  organization’s  software 
process  assets.  The  Integrated  Software  Management  (ISM)  KPA  is  strongly  supported  be¬ 
cause  management  and  engineering  activities  are  integrated  into  the  TSP.  Specific  guidance  is 
provided  for  the  Peer  Review  (PR)  KPA  by  way  of  the  TSP  inspection  process.  Software 
Product  Engineering  (SPE)  activities  are  strongly  supported  through  the  PSP.  The  Intergroup 
Coordination  (IC)  KPA  is  addressed  via  the  team  role  managers.  The  Training  Program  (TP) 
KPA  is  enabled  by  the  TSP  in  that  training  needs  of  projects  are  identified  and  planned. 

Figure  2  shows  the  percentage  of  project  key  practices  addressed  by  the  TSP  for  each  KPA  of 
level  3.  For  detailed  observations  on  each  key  practice  at  level  3,  see  Section  8. 
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Figure  2:  Project  Key  Practices  Profile  at  Level  3 
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5  TSP  and  Level  4 


At  level  3,  defined  processes  enable  the  use  of  process  measures.  Projects  start  to  collect  and 
use  measures  for  planning  and  tracking,  and  an  organization’s  software  process  database  is 
established.  At  level  4,  projects  collect  detailed  measures  for  both  project  processes  and 
product  quality.  Software  product  quality  and  software  process  capability  are  quantitatively 
understood.  Measures  are  used  dynamically  to  manage  both  project  processes  and  quality. 

The  Quantitative  Process  Management  (QPM)  KPA  focuses  on  understanding  and  controlling 
processes  used  by  projects,  collecting  data  on  projects’  process  performance,  and  where  pos¬ 
sible,  using  this  data  to  characterize  the  performance  of  the  organization’s  standard  software 
process.  The  TSP  provides  direct  support  for  quantitative  process  management  for  projects, 
thus  enabling  equivalent  quantitative  analysis  across  the  organization. 


The  TSP  also  provides  explicit  support  for  the  Software  Quality  Management  (SQM)  KPA. 
Product  quality  is  planned,  tracked,  managed,  and  understood. 

Figure  3  shows  the  percentage  of  project  key  practices  addressed  by  the  TSP  for  each  KPA  of 
CMM  level  4.  For  detailed  observations  on  each  key  practice  at  level  4,  see  Section  8. 


Figure  3:  Project  Key  Practices  Profile  at  Level  4 
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6  TSP  and  Level  5 


At  level  5,  the  quantitative  understanding  achieved  at  level  4  drives  a  culture  of  continuous 
improvement.  The  Defect  Prevention  (DP)  KPA  looks  for  common  causes  of  defects  and  at¬ 
tempts  to  prevent  their  recurrence.  The  Process  Change  Management  (PCM)  KPA  looks  to 
continuously  improve  the  software  processes  used  in  the  organization  in  terms  of  reduced 
cycle  time,  productivity  gains,  or  better  quality.  The  Technology  Change  Management  (TCM) 
KPA  specifically  examines  the  potential  impact  of  new  technologies  on  quality  and  produc¬ 
tivity,  and  transitions  appropriate  technologies  into  practice. 

The  TSP  explicitly  addresses  many  of  the  key  practices  for  the  DP  and  PCM  KPAs,  and 
somewhat  less  of  the  TCM  KPA,  again  following  the  pattern  of  supporting  project  activities 
while  enabling  organizational  activities.  Figure  4  shows  the  percentage  of  project  key  prac¬ 
tices  addressed  by  the  TSP  for  each  KPA  of  level  5.  For  detailed  observations  on  each  key 
practice  at  level  5,  see  Section  8. 
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Figure  4:  Project  Key  Practices  Profile  at  Level  5 
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7  Summary  of  the  Relationship  between 
the  TSP  and  SW-CMM 


A  potentially  useful  picture  emerges  from  the  project-  and  organization-level  key  practice 
profiles  of  the  TSP  across  the  SW-CMM  levels.  Of  the  294  key  practices  examined  (all  KPAs 
except  for  SSM  at  level  2),  139  were  classified  as  project  responsibilities,  and  70  were  classi¬ 
fied  as  organization  responsibilities.  The  85  practices  classified  as  having  both  project-  and 
organization-level  responsibility  provide  a  starting  point  for  defining  an  operational  interface 
between  TSP  projects  and  a  CMM-based  improvement  program. 

t 

Table  1  shows  the  classification  of  the  key  practices  by  maturity  level  (see  Section  9  for  de¬ 
tails).  Figure  5  shows  a  summary  of  the  degree  to  which  the  TSP  addresses  key  practices 
classified  as  either  project  level,  or  as  both  organization  and  project  level.  Figure  6  shows  the 
same  data  for  key  practices  classified  as  either  organization  level,  or  as  both  project  and  or¬ 
ganization  level. 


Table  1:  Key  Practice  Classification  Summary 


Level  2 

Level  3 

Level  4 

Level  5 

All  Levels 

Project 

73% 

42% 

45% 

14% 

47% 

Organization 

0% 

37% 

6% 

50% 

24% 

Both  Project  and 
Organization 

27% 

21% 

48% 

36% 

29% 
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Organization  Key  Practices  3  Project  Key  Practices 


Level  2  Level  3  Level  4  Level  5 

CMM  Levels 


jure  5: 


Project  Key  Practices  Profile  -  Summary 


Level  2  Level  3  Level  4  Level  5 

CMM  Levels 


Figure  6:  Organization  Key  Practices  Profile  -  Summary 
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8  Observations  for  CMM  Key  Practices 


This  section  records  detailed  observations  for  each  KPA  of  the  SW-CMM.  First,  information 
about  the  TSP  introduction  strategy  is  provided.  Then,  the  methodology  used  for  recording 
the  observations  is  described.  Next,  global  observations  that  apply  across  most  of  the  KPAs 
are  described.  This  is  followed  by  a  brief  description  of  the  process  elements  of  the  TSP  that 
are  referenced  in  the  observations.  Finally,  the  observations  for  each  KPA  are  presented. 

8.1  The  TSP  Introduction  Strategy 

The  TSP  introduction  strategy  is  designed  to  create  the  right  circumstances  for  introducing 
TSP  in  an  organization.  The  strategy  includes  the  following: 

1 .  a  one-day  TSP  executive  seminar 

2.  a  one-half  to  one-day  executive-planning  session 

3.  four  days  of  training  for  management  in  how  to  lead  and  coach  self-directed  TSP  teams 

4.  two  weeks  of  training  in  the  PSP  for  the  software  engineers 

5.  two  days  of  training  in  a  personal  process  for  non-software  engineers  participating  in 
interdisciplinary  TSP  teams 

6.  three-  to  four-day  team  launches,  with  required  participation  from  senior  management 
and  customer  representatives 

7.  relaunches,  postmortems,  and  checkpoints 


Additional  training  is  required  for  PSP  instructors  and  TSP  launch  coaches.  The  training  in¬ 
volves  all  levels  of  management:  senior  executive,  middle  managers,  first-line  managers, 
software  engineers,  and  members  of  other  groups.  The  TSP  is  first  piloted  on  two  or  more 
teams.  Results  from  the  pilots  are  evaluated,  more  teams  are  trained,  and  the  TSP  is  then 
rolled  out  across  the  organization. 

8.2  Methodology  for  Observations 

The  methodology  used  to  record  the  observations  for  each  KPA  is  as  follows: 

1 .  Two  tables  were  created  for  each  KPA  of  the  SW-CMM. 

2.  In  the  first  table,  rows  for  each  goal  of  the  KPA  were  created.  For  each  goal 
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a.  the  first  column  lists  the  goal  statement  from  the  SW-CMM 

b.  the  second  column  describes  how  the  TSP  addresses  the  goal.  The  second  column 
also  indicates  the  degree  to  which  the  goal  is  addressed  by  the  TSP.  “Fully  ad¬ 
dressed”  means  the  TSP  fully  satisfies  the  goal,  with  no  significant  weaknesses 
identified.  “Not  addressed”  means  the  TSP  does  not  address  the  goal  at  all,  and 
“Partially  addressed”  means  the  goal  is  addressed  to  some  degree,  but  no  significant 
weaknesses  were  identified. 

3.  In  the  second  table,  rows  for  each  key  practice  of  the  KPA  were  created.  For  each  key 

practice 

a.  the  first  column  lists  the  key  practices  from  the  SW-CMM 

b.  the  “TSP  Element”  column  references  the  TSP  scripts,  specifications,  forms,  or 
documents  that  address  the  key  practice 

c.  the  “Observation”  column  records  one  or  more  comments  about  how  TSP  addresses 
the  key  practice 

d.  the  “Project  Level”  column  indicates  the  degree  to  which  the  key  practice  is  ad¬ 
dressed  at  the  project  level.  “Fully  addressed”  means  the  TSP  fully  satisfies  the  in¬ 
tent  of  the  key  practice  at  the  project  level.  “Not  addressed”  means  the  TSP  does 
not  satisfy  the  intent  of  the  key  practice  at  the  project  level.  “Partially  addressed” 
means  the  key  practice  is  addressed  to  some  degree,  but  not  enough  to  fully  satisfy 
the  intent  of  the  SW-CMM.  “Not  applicable”  means  the  key  practice  was  classified 
as  an  “organization-level”  practice  in  Section  9. 

e.  the  “Org.  Level”  column  indicates  the  degree  to  which  the  key  practice  is  addressed 
at  the  organization  level.  Though  the  focus  of  the  TSP  is  at  the  project  level,  it  ad¬ 
dresses  several  key  practices  at  the  organization  level  as  well.  Fully  addressed 
means  the  TSP  fully  satisfies  the  intent  of  the  key  practice  at  the  organization  level. 
“Not  addressed”  means  the  TSP  does  not  satisfy  the  intent  of  the  key  practice  at  the 
organization  level.  “Partially  addressed”  means  the  key  practice  is  addressed  to 
some  degree,  but  not  enough  to  fully  satisfy  the  intent  of  the  SW-CMM.  “Not  ap¬ 
plicable”  means  the  key  practice  was  classified  as  a  “project-level”  practice  in  Sec¬ 
tion  9. 

f.  the  “Notes”  column  contains  supporting  notes  for  the  observation.  In  particular,  this 
column  explains  why  a  key  practice  is  partially  addressed. 


8.3  Global  Observations 

The  following  global  observations  can  be  made  about  how  the  TSP  supports  the  common 
features  of  the  SW-CMM.  They  will  not  be  repeated  in  the  observations  for  each  KPA. 


8.3.1  Commitment  to  Perform 

“Where  policy  statements  are  used,  they  generally  refer  to  the  project  following  a  written, 
organizational  policy  for  the  practices  of  that  key  process  area.  This  is  to  emphasize  the  con¬ 
nection  between  organizational  commitment  and  the  projects  that  are  actually  performing  the 
work.  The  subpractices  for  the  policy  statement  generally  summarize  activities  that  are  cov- 
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ered  later  in  the  KPA  and  are  particularly  suitable  to  institutionalization  via  a  written  policy. 

In  some  KPAs  (such  as  Organization  Process  Focus),  the  focus  of  the  activities  for  the  KPA  is 
the  organization,  not  the  project.  In  those  cases,  the  policy  statement  is  reworded  and  refers  to 
the  organization  following  a  written  policy”  [Paulk  95]. 

Organizational  policies  must  be  created  at  the  organization  level.  At  the  project  level,  these 
policies  must  be  followed  and  projects  must  exhibit  behaviors  consistent  with  these  policies. 
The  TSP  does  not  address  creation  of  organizational  policies.  However,  TSP  teams  usually 
exhibit  behaviors  consistent  with  such  policies,  if  they  exist.  The  TSP  does  not  fully  address 
any  of  the  key  practices  in  the  Commitment  to  Perform  common  feature  that  require  a  written 
organization  policy.  Observations  for  these  key  practices  in  this  technical  report  will  address 
only  non-policy  issues  specified  by  these  practices,  if  any. 


8.3.2  Ability  to  Perform 

“Most  key  process  areas  of  the  SW-CMM  contain  a  key  practice  that  reflects  the  need  for 
adequate  resources  and  funding  for  the  activities  covered  by  the  key  process  area.  These  re¬ 
sources  and  funding  generally  fall  into  three  categories:  access  to  special  skills,  adequate 
funding,  and  access  to  tools”  [Paulk  95]. 

The  TSP  launch  process  ensures  that  adequate  resources  and  funding  are  provided  for  all  pro¬ 
ject  activities.  During  the  launch,  the  tools  and  special  skills  needed  are  identified.  At  the 
conclusion  of  a  launch,  the  team  presents  its  needs  to  management.  Management  approves 
the  team  plan,  and  gives  the  team  the  go-ahead  to  start  executing  the  plan.  The  Support  Man¬ 
ager  role  is  responsible  for  tools  used  and  needed  by  the  team.  This  key  practice  is  fully  ad¬ 
dressed  by  the  TSP  whenever  resources  and  funding  are  needed  for  project-level  activities. 


8.3.3  Verifying  Implementation 

“The  Verifying  Implementation  common  feature  generally  contains  key  practices  that  relate 
to  oversight  by  senior  management  and  project  management,  as  well  as  specific  verification 
activities  that  the  software  quality  assurance  group  or  others  are  expected  to  perform  to  verify 
that  the  key  practices  are  being  performed  properly”  [Paulk  95]. 

Management  Oversight 

Senior  management  oversight  (Verification  1)  and  project  management  oversight  (Verifica¬ 
tion  2)  are  integral  to  the  TSP.  Management  is  involved  in  the  team  launch,  and  understands 
and  commits  to  the  team  plan.  Several  status  and  review  meetings  and  reports  are  defined  in 
the  TSP.  These  include  the  following: 
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•  TSP  Launch  (Script  LAU) 

•  TSP  Project  Status  Report  (Specification  STATUS) 

•  TSP  Project  Summary  Report  (Specification  SUMMARY) 

•  TSP  Management  and  Customer  Status  Meeting  (Script  STATUS) 

•  TSP  Weekly  Team  Meeting  (Script  WEEK) 

•  TSP  Quarterly  Executive  Project  Review  Checklist  (REVCL) 

•  TSP  Plan  Review  Checklist  for  Executives  (PLANCL) 

Observations  for  Verification  1  and  Verification  2  will  not  repeat  this  integral  oversight  proc¬ 
ess  that  is  built  into  the  TSP. 

Software  Quality  Assurance  (SQA) 

TSP  teams  address  SQA  as  it  would  typically  be  addressed  in  high-maturity  organizations. 
Process  and  product  data  are  analyzed  to  determine  the  quality  of  the  work  products  and  the 
quality  of  the  process  used  to  create  the  work  products.  This  contrasts  with  the  more  work- 
product-oriented  SQA  in  lower-maturity  organizations,  where  people  audit  and  examine 
processes  and  work  products  to  determine  their  quality. 

Humphrey  makes  the  following  observation  about  the  changing  scope  of  the  SQA  function  in 
a  high-maturity  organization:  “. .  .The  software  professionals  and  managers  will  generally  do 
their  own  quality  assurance.  They  will  measure  their  work,  assess  trends,  and  take  corrective 
action.”  He  goes  on  to  say  that  even  at  the  higher  maturity  levels,  QA  must  include  tasks 
such  as  “statistically  sample  the  software  engineering  work  to  ensure  it  is  performed  to  stan¬ 
dard,  sample  the  data  to  assure  that  it  represents  the  work  being  done,  and  analyze  the  data 
and  alert  management  to  any  out-of-line  trends  or  conditions”  [Humphrey  89]. 

TSP  teams  fulfill  this  view  of  SQA.  TSP  teams  are  self-managed  and  are  responsible  for  both 
their  product  and  process  quality.  TSP  teams  use  data  to  assure  quality.  The  Quality  Manager 
on  a  TSP  team  has  overall  responsibility  for  both  process  and  product  quality.  Role  managers 
monitor  the  quality  for  their  particular  areas  of  responsibilities.  They  try  to  resolve  non- 
compliance  issues  with  team  members  and  the  Team  Leader.  In  addition,  the  TSP  checkpoint 
process  ensures  the  team  is  following  its  processes  and  procedures.  An  authorized  TSP  launch 
coach,  who  typically  is  not  a  team  member,  conducts  TSP  checkpoints.  Checkpoint  findings 
are  discussed  with  the  team  and  the  Team  Leader. 

Observations  for  SQA  oversight  (Verification  3)  address  the  software  quality  assurance  ac¬ 
tivities  performed  by  a  TSP  team.  TSP  teams  perform  quality  assurance  functions,  regardless 
of  the  existence  of  an  external  SQA  group.  Where  an  independent  SQA  group  exists,  the  TSP 
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suggests  that  the  team’s  Quality  Manager  work  cooperatively  with  the  SQA  group  in  oversee¬ 
ing  the  team’s  product  and  process  quality. 

8.4  Process  Elements  of  the  TSP 

The  TSP  includes  more  than  70  process  elements  to  guide  the  work  of  TSP  teams.  Process 
scripts  define  processes  ranging  from  project  planning  processes  to  project  postmortem  proc¬ 
esses.  Forms  define  data  gathering  and  analysis  for  various  processes  and  procedures.  Exam¬ 
ples  include  the  team  inspection  data  recording  form  and  the  product  size  summary  data  re¬ 
cording  form.  Checklists,  specifications,  and  standards  are  included  to  support  project 
processes  and  procedures.  Examples  are  the  quarterly  project  review  checklist  for  executives 
or  the  management  status  report  specification. 

The  following  process  elements  of  the  TSP  are  referenced  in  the  ‘TSP  Element”  column  of 
the  observation  tables. 


8.4.1  TSP  Scripts 

All  TSP  scripts  are  listed  in  the  following  table.  After  the  first  two,  the  scripts  are  listed  in  the 
alphabetical  order  of  their  abbreviated  names. 


Table  2:  TSP  Scripts 


Script 

Abbreviation 

Script  Name  ;/• 

DEV 

Overall  Development  and  Enhancement  Process 

MAINT 

Overall  Maintenance  and  Enhancement  Process 

ANA 

Impact  Analysis 

HLD 

High  Level  Design 

IMP 

Implementation 

IMP6 

Unit  Test  and  Test  Development  (step  6  in  script  IMP) 

INS 

Inspection  Process  (two  pages) 

LAU 

Team  Launch 

Launch  Meeting  1  -  Launch  overview  and  kick-off 

LAU2 

Launch  Meeting  2  -  Roles  and  goals 

LAU3 

Launch  Meeting  3  -  Strategy,  process,  support 

LAU4 

Launch  Meeting  4  -  Overall  team  plan 

LAU5 

Launch  Meeting  5  -  Quality  plan 

LAU6 

Launch  Meeting  6  -  Detailed  next-phase  plans 

LAU7 

Launch  Meeting  7  -  Risk  assessment 

LAU8 

Launch  Meeting  8  -  Management  meeting  preparation 
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Script 

Script  Name  ' 

Abbreviation 

.  '  ,  \  ..  -  .  -  •: 

LAU9 

Launch  Meeting  9  -  Wrap-up  management  meeting 

LAUPM 

Launch  Postmortem  Meeting  -  Postmortem  on  the  launch 

MTG 

General  Meeting  Process 

PM 

Project  Postmortem 

REL 

Team  Relaunch 

REL1 

Relaunch  Meeting  1  -  Status  and  management  update 

REQ 

Requirements 

STATUS 

Management  and  Customer  Status  Meeting 

TEST 

Release  Test 

TEST1 

Product  Build  (step  1  in  script  TEST) 

TEST2 

Integration  (step  2  in  script  TEST) 

TEST3 

System  Test  (step  3  in  script  TEST) 

TESTD 

Test  Defect  Handling 

WEEK 

Weekly  Team  Meeting 

8.4.2  TSP  Forms 

All  of  the  TSP  forms  and  instructions  for  the  forms  are  listed  here  in  the  alphabetical  order  of 
their  abbreviations. 


Table  3:  TSP  Forms 


Form  « 

Abbreviation  C 

FormandlnstfuctlonsName  ;;4>  1  r; 

DEFECT 

Defect  Reporting  Form 

GOAL 

Team  Goals 

INS 

Inspection  Report 

INV 

Process  Inventory 

ITL 

Issue/Risk  Tracking  Log 

LOGD 

Defect  Recording  Log 

LOGT 

Time  Recording  Log 

MTG 

Meeting  Report  Form 

PIP 

Process  Improvement  Proposal 

ROLE 

Team  Roles 

ROLEMX 

Role  Assignment  Matrix 

SCHED 

Schedule  Planning  Template 

STRAT 

Strategic  Planning  Form 

SUMDI 

Defects  Injected  Summary 

SUMDR 

Defects  Removed  Summary 

SUMP 

Plan  Summary  Form 
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Form 

Form  and  Instructions  Name 

Abbreviation 

SUMQ 

Quality  Summary  Form 

Program  Size  Summary 

Development  Time  Summary  Form 

SUMTASK 

Task  Plan  Summary 

TASK 

Task  Planning  Template 

TESTLOG 

Test  Log 

WEEK 

Weekly  Status  Report 

8.4.3  TSP  Role  Specifications 

The  role  specifications  provide  guidance  for  people  who  fill  each  role,  and  list  each  role’s 
principal  duties  and  responsibilities. 

Table  4:  TSP  Role  Specifications 

Role  Descriptions 


Team  member 


General  responsibilities  of  team  members 


Customer  Interface  Manager  responsibilities 


Customer  Interface  Manager 


Design  Manager  responsibilities 
Implementation  Manager  responsibilities 


Design  Manager 
Implementation  Manager 


Planning  Manager  responsibilities 
Process  Manager  responsibilities 
Quality  Manager  responsibilities 


Planning  Manager 
Process  Manager 
Quality  Manager 


Support  Manager  responsibilities 
Test  Manager  responsibilities 


Meeting  roles  and  responsibilities 


Inspection  roles  and  responsibilities 


Team  Leader  responsibilities 
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8.4.4  TSP  Checklists,  Specifications,  and  Standards 

The  TSP  checklists,  specifications,  and  standards  are  listed  in  alphabetical  order. 


Table  5:  TSP  Checklists,  Specifications,  andStandards 


Abbreviation 

Checklist,  Specification, 

or  Standard 

NOTEBOOK 

The  specification  for  the  project  notebook 

PLAN 

Planning  standard  -  standard  planning  factors 

PLANCL 

Plan  assessment  checklist  for  executives 

PREPL 

Launch  preparation  checklist 

PREPR 

Relaunch  preparation  checklist 

QUAL 

Quality  standard  -  standard  quality  plan  factors 

REVCL 

Quarterly  project  review  checklist  for  executives 

STATUS 

Management  status  report  specification 

SUMMARY 

Project  summary  report  specification 

8.4.5  Other  Sources  of  Information 

Other  sources  of  information  in  the  “TSP  Element”  column  include  the  following: 

•  the  Personal  Software  Process,  as  defined  in  A  Discipline  for  Software  Engineering 
[Humphrey  95] 

•  the  executive  review  process,  as  defined  in  Winning  with  Software:  An  Executive  Survival 
Strategy  [Humphrey  02] 

•  the  roles  of  TSP  launch  coach  and  Team  Leader,  as  defined  in  Leading  and  Coaching 
Disciplined  Teams  [Humphrey,  in  press] 

•  PSP  and  TSP  training  materials  used  in  the  TSP  introduction  strategy 

•  the  TSP  prototype  tool,  which  facilitates  planning,  tracking,  data  collection,  and  data 
analysis  for  TSP  teams 

•  TSP  and  PSP  measures,  such  as  Process  Quality  Index  (PQI),  defined  in  the  PSP  and  TSP 
textbooks 

•  TSP  data  analysis  charts,  such  as  the  TSP  quality  profile  described  in  TSP  textbooks 
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TU  fllIwlilM  sibility  to  help  the  team  and  team  members  run  addressed  addressei 

The  software  quality  assurance  ,/  .  t  , 

A!  a  *  a  well-planned  and  tracked  project, 

group  reviews  and/or  audits  the  r  r  J 

activities  and  work  products  for  Also,  see  global  observations  in  Section  8.3. 

software  project  planning,  and 
reports  the  results. 


8.7  Software  Project  Tracking  and  Oversight  Observations 

“The  purpose  of  Software  Project  Tracking  and  Oversight  is  to  provide  adequate  visibility  into  actual  progress  so  that  management  can  take 
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Corrective  actions  are  taken  and  managed  to  closure  when  TSP  teams  make  small  adjustments  to  plans  dynamically  on  a  weekly  basis  to  minimize  deviation  between  actual 
actual  results  and  performance  deviate  significantly  from  the  results  and  the  plan.  When  the  deviation  is  significant,  the  teams  go  through  a  relaunch  to  replan  their  work.  This 
software  plans.  goal  is  fully  addressed  by  the  TSP. 
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tual  design  of  the  product,  the  technical  tasks  to 
be  performed,  the  technical  risks,  and  all  other 
technical  aspects  of  the  project. 
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ing  and  Oversight  Key  ;  Level  Level 

Practice  ~  ;v  ’  .  '  -  *  ‘V  M  \  §S: 


(STATUS).  Results  of  corrective  actions  are 
reflected  in  the  NOTEBOOK. 
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Objectivity  is  built  in  because  process  and  product  quality  are  tracked  through  data.  Objectivity  is  also  promoted  through  the  TSP  checkpoint 
process.  An  SEI-authorized  TSP  launch  coach  periodically  conducts  the  TSP  checkpoint.  The  launch  coach  is  usually  not  a  team  member.  Dur¬ 
ing  this  one-  to  two-day  checkpoint,  the  launch  coach  analyzes  team  data.  The  coach  also  meets  with  team  members,  the  Team  Leader,  and 
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This  information  comes  from  a  draft  version  of  Leading  and  Coaching  Disciplined  Teams  Using  the  Team  Software  ProcessSM  (TSP*M)  written  by  Watts 
Humphrey. 
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8.10  Software  Configuration  Management  Observations 
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SCM  processes.  The  TSPi  [Humphrey  00]  includes  processes  for  change  control  and  configuration  management.  Most  TSP  teams  use  or  mod¬ 
ify  these  processes  in  the  absence  of  existing  SCM  processes. 


The  observations  for  this  KPA  assume  that  the  TSP  team  is  responsible  for  its  own  software  configuration  management.  If  the  teams  are  work¬ 
ing  in  an  organization  where  an  external  SCM  group  exists,  and  that  group  is  not  using  the  TSP,  these  observations  may  not  be  valid. 
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If  all  projects  in  an  organization  are  using  the  TSP,  and  the  organization  has  adopted  the  standard  TSP  introduction  strategy,  then  the  goals  of 
coordinating  and  planning  software  process  improvement  activities  are  largely  addressed  at  the  project  level.  However,  some  process  im¬ 
provement  activities  at  the  organization  level  are  not  addressed  by  the  TSP.  Some  examples  of  such  activities  would  be  organization-wide  con- 


figuration  management,  subcontract  management,  training  program,  cross-project  data  analysis,  and  technology  change  management.  Overall, 
the  focus  of  this  KPA  is  at  the  organization  level,  not  at  the  project  level.  The  TSP  mainly  enables  the  key  practices  of  this  KPA. 
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Goal  3 

Organization-level  process  development  and  improvement  The  TSP  introduction  strategy  includes  planning  for  introduction  of  the  TSP  into  an  organization.  TSP  teams  plan 
activities  are  planned.  to  build  the  process  elements  needed  by  the  teams.  TSP  teams  also  plan  to  address  Process  Improvement  Proposals 
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8.12  Organization  Process  Definition  Observations 

“The  purpose  of  Organization  Process  Definition  is  to  develop  and  maintain  a  usable  set  of  software  process  assets  that  improve  process  per- 
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Goal  2 

Information  related  to  the  use  of  the  organization’s  Projects  collect,  review,  and  use  metrics  and  other  information  related  to  the  use  of  their  processes. 

standard  software  process  by  the  software  projects  is  An  organization-level  function  that  makes  this  information  available  for  use  by  projects  across  the  organization  is  be- 


process  assets  receive  required 
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ties. 
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presented  to  management  and  customer  repre¬ 
sentatives  for  approval. 
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When  organizations  adopt  the  TSP,  training  is  specified  for  all  levels  of  the  management  chain,  down  to  the  practicing  developers,  including 
non-software  personnel.  However,  TSP  introduction  does  not  specify  organization-specific  non-TSP  training,  so  this  process  area  in  general 


can  only  be  partially  addressed  by  widespread  adoption  of  the  TSP.  Most  project-level  training  practices  of  the  TSP  are  recognized  in  specific 
institutionalization  features  (Abilities)  in  the  other  KPAs. 
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Software  managers  receive  orien-  executive  and  manage-  training  specified  by  the  introduction  strategy,  applicable  addressed  TSP  training  and  coaching.  Other  training 

tation  on  the  training  program.  ment  training  all  levels  of  management  are  exposed  to  the  is  not  addressed. 

scope  and  nature  of  PSP/TSP  training  for  the 
entire  organization. 
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already  possess  the  knowledge  knowledge  and  skills, 

and  skills  required  to  perform  in 
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estimates  size  for  all  product  types 
creates  an  earned  value  plan 

creates  a  CM  plan,  support  plan,  process  plan,  and  quality  plan 


creates  individual  plans  for  each  team  member,  and  performs  load  balancing 
consolidates  individual  plans  into  a  team-level  plan 
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(for  example,  the  REQ  and  ANA  scripts  for  requirements,  HLD  for  high-level  design,  and  IMP  for  detailed  design  and  implementation).  Role 
managers  have  specific  responsibilities  for  engineering  activities  (for  example,  the  Customer  Interface  Manager  is  responsible  for  require¬ 
ments  activities,  the  Design  Manager  for  design  activities,  and  the  Test  Manager  for  test  activities). 
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8.16  Intergroup  Coordination  Observations 

“The  purpose  of  Intergroup  Coordination  is  to  establish  a  means  for  the  software  engineering  group  to  participate  actively  with  the  other  engi- 
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integrated  product  team,  thus  promoting  intergroup  coordination.  Requirements  teams  may  also  include  software  engineers  and  representatives 
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8.21  Technology  Change  Management  Observations 

“The  purpose  of  Technology  Change  Management  is  to  identify  new  technologies  (i.e.,  tools,  methods,  and  processes)  and  track  them  into  the 
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9  Classification  of  CMM  Key  Practices 


The  scope  of  the  TSP  is  the  mainly  the  project,  whereas  the  scope  of  the  SW-CMM  covers 
both  the  organization  and  the  projects  in  an  organization.  To  record  observations  about  how 
the  TSP  addresses  key  practices  of  the  SW-CMM,  each  key  practice  of  the  SW-CMM  was 
classified  to  determine  at  what  level  of  the  organization  the  SW-CMM  intends  the  key  prac¬ 
tice  to  be  addressed. 

A  classification  of  “Project”  means  the  intent  of  the  SW-CMM  is  for  the  project  to  be  respon¬ 
sible  for  addressing  the  key  practice.  A  classification  of  “Organization”  means  the  intent  is 
for  the  organization  to  be  responsible  for  addressing  the  key  practice.  A  classification  of  “Pro¬ 
ject  and  Organization”  means  both  the  organization  and  project  are  responsible  for  addressing 
the  key  practice. 


Classifying  a  key  practice  as  a  project-level  key  practice  does  not  mean  that  the  organization 
has  no  role  to  play.  Organizations  must  support  projects  in  all  their  activities.  Classifying  a 
key  practice  as  a  project-level  key  practice  means  that  the  project  has  the  principle  responsi¬ 
bility  of  addressing  that  key  practice,  using  organizational  support  as  needed. 

Similarly,  classifying  a  key  practice  as  an  organization-level  key  practice  does  not  mean  that 
the  projects  have  no  role  to  play.  Classifying  a  key  practice  as  an  organization-level  key  prac¬ 
tice  means  that  the  organization  has  the  principle  responsibility  of  addressing  that  key  prac¬ 
tice,  using  project  support  as  needed. 

An  example  of  a  key  practice  that  is  classified  as  organization-level  is  Commitment  1  of  the 
Defect  Prevention  KPA,  which  states,  ‘The  organization  follows  a  written  policy  for  defect 
prevention  activities.”  An  example  of  a  key  practice  that  is  classified  as  both  organization- 
level  and  project-level  is  Commitment  2  of  the  Defect  Prevention  KPA,  which  states,  ‘The 
project  follows  a  written  organizational  policy  for  defect  prevention  activities.”  In  the  former 
case,  the  key  practice  calls  for  the  organization  to  follow  an  organizational  policy;  thus,  the 
intent  of  the  SW-CMM  is  for  that  key  practice  to  be  addressed  at  the  organization  level.  In 
the  latter  case,  the  key  practice  calls  for  the  project  to  follow  an  organizational  policy;  thus, 
the  intent  of  the  SW-CMM  is  for  the  key  practice  to  be  addressed  at  both  the  organization  and 
at  the  project  levels. 
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An  example  of  a  key  practice  that  is  classified  as  project-level  is  Activity  7  of  the  Software 
Project  Planning  KPA,  which  states,  ‘The  plan  for  the  software  project  is  documented.”  It  is 
the  project’s  responsibility  to  ensure  that  the  plan  is  documented,  even  though  the  project 
may  use  other  organizational  resources  to  do  this. 

Overall,  the  classifications  follow  the  broad  focus  of  each  SW-CMM  KPA.  KPAs  which  fo¬ 
cus  on  projects  include 

•  Requirements  Management 

•  Software  Project  Planning 

•  Software  Project  Tracking  and  Oversight 

•  Software  Quality  Assurance 

•  Software  Configuration  Management 

•  Integrated  Software  Management 

•  Software  Product  Engineering 

•  Intergroup  Coordination 

•  Peer  Review 

•  Software  Quality  Management 

KPAs  that  focus  on  both  the  project  and  the  organization  include 

•  Quantitative  Process  Management 

•  Defect  Prevention 

KPAs  that  focus  on  the  organization  include 

•  Organization  Process  Focus 

•  Organization  Process  Definition 

•  Training  Program 

•  Technology  Change  Management 

•  Process  Change  Management 

9.1  Methodology  for  Classification 

To  classify  the  key  practices,  tables  were  created  for  each  KPA  of  the  SW-CMM.  Each  row  in 
a  KPA  table  represents  one  key  practice  in  that  KPA.  The  first  column  in  the  table  identifies 
the  key  practice  being  classified.  Key  practices  are  identified  by  combining  the  name  of  the 
SW-CMM  common  feature  with  the  number  of  the  key  practice.  For  example,  the  first  key 
practice  of  the  Ability  to  Perform  common  feature  is  titled  “Ability  1.”  The  second  key  prac- 
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tice  of  the  Commitment  to  Perform  common  feature  is  labeled  “Commitment  2.”  The  second 
column  in  the  table  classifies  the  level  at  which  the  SW-CMM  intends  the  key  practice  to  be 
addressed.  The  last  column  in  the  table  contains  notes  describing  the  reason  for  the  classifica¬ 
tion. 


9.2  Key  Practice  Classification  for  Requirements 
Management  _ 


Key 

Practice 

Classification 

Notes  .  ;■  • 

Commitment  1 

Project  and  Organi¬ 
zation 

Both  the  organization  and  the  project  are  responsible  for  ensuring  that  the 
project  follows  a  written  organizational  policy  for  managing  the  system 
requirements  allocated  to  software. 

Ability  1 

Project 

The  project  is  responsible  for  ensuring  that  for  each  project,  responsibility  is 
established  for  analyzing  the  system  requirements  and  allocating  them  to 
hardware,  software,  and  other  system  components. 

Ability  2 

Project 

The  project  is  responsible  for  ensuring  that  the  allocated  requirements  are 
documented. 

Ability  3 

Project  and  Organi¬ 
zation 

Both  the  organization  and  the  project  are  responsible  for  ensuring  that  ade¬ 
quate  resources  and  funding  are  provided  for  managing  the  allocated  re¬ 
quirements. 

Ability  4 

Project 

The  project  is  responsible  for  ensuring  that  members  of  the  software  engi¬ 
neering  group  and  other  software-related  groups  are  trained  to  perform  their 
requirements  management  activities. 

Activity  1 

Project 

The  project  is  responsible  for  ensuring  that  the  software  engineering  group 
reviews  the  allocated  requirements  before  they  are  incorporated  into  the 
software  project. 

Activity  2 

Project 

The  project  is  responsible  for  ensuring  that  the  software  engineering  group 
uses  the  allocated  requirements  as  the  basis  for  the  software  plans,  work 
products,  and  activities. 

Activity  3 

Project 

The  project  is  responsible  for  ensuring  that  changes  to  the  allocated  re¬ 
quirements  are  reviewed  and  incorporated  into  the  software  project. 

Measurement  1 

Project 

The  project  is  responsible  for  ensuring  that  measurements  are  made  and 
used  to  determine  the  status  of  the  activities  for  managing  allocated  re¬ 
quirements. 

Verification  1 

Project  and  Organi¬ 
zation 

Both  the  organization  and  the  project  are  responsible  for  ensuring  that  the 
activities  for  managing  the  allocated  requirements  are  reviewed  with  senior 
management  on  a  periodic  basis. 

Verification  2 

Project 

The  project  is  responsible  for  ensuring  that  the  activities  for  managing  the 
allocated  requirements  are  reviewed  with  the  project  manager  on  both  a 
periodic  and  event-driven  basis. 
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Key 

Practice 

Classification 

Notes  '  v 

Verification  3 

Project  and  Organi¬ 
zation 

Both  the  organization  and  the  project  are  responsible  for  ensuring  that  the 
software  quality  assurance  group  reviews  and/or  audits  the  activities  and 
work  products  for  managing  the  allocated  requirements  and  reports  the  re¬ 
sults. 

9.3  Key  Practice  Classification  for  Software  Project 
Planning 


Key  ; 
Practice 

Classification! 

.  ■  ?  ■  ...  *■ 

Commitment  1 

Project  and  Organi¬ 
zation 

Both  the  organization  and  the  project  are  responsible  for  ensuring  that  a 
project  software  manager  is  designated  to  be  responsible  for  negotiating 
commitments  and  developing  the  project’s  software  development  plan. 

Commitment  2 

Project  and  Organi¬ 
zation 

Both  the  organization  and  the  project  are  responsible  for  ensuring  that  the 
project  follows  a  written  organizational  policy  for  planning  a  software  pro¬ 
ject. 

Ability  I 

Project 

The  project  is  responsible  for  ensuring  that  a  documented  and  approved 
statement  of  work  exists  for  the  software  project. 

Ability  2 

Project 

The  project  is  responsible  for  ensuring  that  responsibilities  for  developing 
the  software  development  plan  are  assigned. 

Ability  3 

Project  and  Organi¬ 
zation 

Both  the  organization  and  the  project  are  responsible  for  ensuring  that  ade¬ 
quate  resources  and  funding  are  provided  for  planning  the  software  project. 

Ability  4 

Project 

The  project  is  responsible  for  ensuring  that  the  software  managers,  software 
engineers,  and  other  individuals  involved  in  the  software  project  planning 
are  trained  in  the  software  estimating  and  planning  procedures  applicable  to 
their  areas  of  responsibility. 

Activity  1 

Project  and  Organi¬ 
zation 

Both  the  organization  and  the  project  are  responsible  for  ensuring  that  the 
software  engineering  group  participates  on  the  project  proposal  team. 

Activity  2 

Project 

The  overall  project  is  responsible  for  ensuring  that  software  project  planning 
is  initiated  in  the  early  stages  of,  and  in  parallel  with,  the  overall  project 
planning. 

Activity  3 

Project 

The  project  is  responsible  for  ensuring  that  the  software  engineering  group 
participates  with  other  affected  groups  in  the  overall  project  planning 
throughout  the  project’s  life. 

Activity  4 

Project 

The  project  is  responsible  for  ensuring  that  software  project  commitments 
made  to  individuals  and  groups  external  to  the  organization  are  reviewed 
with  senior  management  according  to  a  documented  procedure. 

Activity  5 

Project 

The  project  is  responsible  for  ensuring  that  a  software  life  cycle  with  prede¬ 
fined  stages  of  manageable  size  is  identified  or  defined. 
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Key 

Practice 

Classification 

Notes 

Activity  6 

Project 

The  project  is  responsible  for  ensuring  that  the  project’s  software  develop¬ 
ment  plan  is  developed  according  to  a  documented  procedure. 

Activity  7 

Project 

The  project  is  responsible  for  ensuring  that  the  plan  for  the  software  project 
is  documented. 

Activity  8 

Project 

The  project  is  responsible  for  ensuring  that  software  work  products  that  are 
needed  to  establish  and  maintain  control  of  the  software  project  are  identi¬ 
fied. 

Activity  9 

Project 

The  project  is  responsible  for  ensuring  that  estimates  for  the  size  of  the  soft¬ 
ware  work  products  (or  changes  to  the  size  of  software  work  products)  are 
derived  according  to  a  documented  procedure. 

Activity  10 

Project 

The  project  is  responsible  for  ensuring  that  estimates  for  the  software  pro¬ 
ject’s  effort  and  costs  are  derived  according  to  a  documented  procedure. 

Activity  1 1 

Project 

The  project  is  responsible  for  ensuring  that  estimates  for  the  project’s  critical 
computer  resources  are  derived  according  to  a  documented  procedure. 

Activity  12 

Project 

The  project  is  responsible  for  ensuring  that  the  project’s  software  schedule  is 
derived  according  to  a  documented  procedure. 

Activity  13 

Project 

The  project  is  responsible  for  ensuring  that  the  software  risks  associated  with 
the  cost,  resource,  schedule,  and  technical  aspects  of  the  project  are  identi¬ 
fied,  assessed,  and  documented. 

Activity  14 

Project 

The  project  is  responsible  for  ensuring  that  plans  for  the  project’s  software 
engineering  facilities  and  support  tools  are  prepared. 

Activity  15 

Project 

The  project  is  responsible  for  ensuring  that  software  planning  data  are  re¬ 
corded. 

Measurement  1 

Project 

The  project  is  responsible  for  ensuring  that  measurements  are  made  and  used 
to  determine  the  status  of  the  software  planning  activities. 

Verification  1 

Project  and  Organi¬ 
zation 

Both  the  organization  and  the  project  are  responsible  for  ensuring  that  the 
activities  for  software  project  planning  are  reviewed  with  senior  manage¬ 
ment  on  a  periodic  basis. 

Verification  2 

Project 

The  project  is  responsible  for  ensuring  that  the  activities  for  software  project 
planning  are  reviewed  with  the  project  manager  on  both  a  periodic  and 
event-driven  basis. 

Verification  3 

Project  and  Organi¬ 
zation 

Both  the  organization  and  the  project  are  responsible  for  ensuring  that  the  j 

software  quality  assurance  group  reviews  and/or  audits  the  activities  and 
work  products  for  software  project  planning  and  reports  the  results. 
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9.4  Key  Practice  Classification  for  Software  Project 
Tracking  and  Oversight _ _ _ 


Key  r  '-.'-'V'.: 
Practice  V:;..'.' 

- 

Classification'’ 

Commitment  1 

Project  and 
Organization 

Both  the  organization  and  the  project  are  responsible  for  ensuring  that  a  project 
software  manager  is  designated  to  be  responsible  for  the  project’s  software  ac¬ 
tivities  and  results. 

Commitment  2 

Project  and 
Organization 

Both  the  organization  and  the  project  are  responsible  for  ensuring  that  the  pro¬ 
ject  follows  a  written  organizational  policy  for  managing  the  software  project. 

Ability  1 

Project 

The  project  is  responsible  for  ensuring  that  a  software  development  plan  for  the 
software  project  is  documented  and  approved. 

Ability  2 

Project 

The  project  is  responsible  for  ensuring  that  the  project  software  manager  explic¬ 
itly  assigns  responsibility  for  software  work  products  and  activities. 

Ability  3 

Project  and 
Organization 

Both  the  organization  and  the  project  are  responsible  for  ensuring  that  adequate 
resources  and  funding  are  provided  for  tracking  the  software  project. 

Ability  4 

Project 

The  project  is  responsible  for  ensuring  that  the  software  managers  are  trained  in 
managing  the  technical  and  personnel  aspects  of  the  software  project. 

Ability  5 

Project 

The  project  is  responsible  for  ensuring  that  first-line  software  managers  receive 
orientation  in  the  technical  aspects  of  the  software  project. 

Activity  1 

Project 

The  project  is  responsible  for  ensuring  that  a  documented  software  development 
plan  is  used  for  tracking  the  software  activities  and  communicating  status. 

Activity  2 

Project 

The  project  is  responsible  for  ensuring  that  the  project’s  software  development  ! 
plan  is  revised  according  to  a  documented  procedure. 

Activity  3 

Project  and 
Organization 

Both  the  organization  and  the  project  are  responsible  for  ensuring  that  software 
project  commitments  and  changes  to  commitments  made  to  individuals  and 
groups  external  to  the  organization  are  reviewed  with  senior  management  ac¬ 
cording  to  a  documented  procedure. 

Activity  4 

Project  and 
Organization 

Both  the  organization  and  the  project  are  responsible  for  ensuring  that  approved 
changes  to  commitments  that  affect  the  software  project  are  communicated  to 
the  members  of  the  software  engineering  group  and  other  software-related 
groups. 

Activity  5 

Project 

The  project  is  responsible  for  ensuring  that  the  size  of  the  software  work  prod¬ 
ucts  (or  size  of  the  changes  to  the  software  work  products)  is  tracked  and  cor¬ 
rective  actions  are  taken  as  necessary. 

Activity  6 

Project 

The  project  is  responsible  for  ensuring  that  the  project’s  software  effort  and 
costs  are  tracked  and  corrective  actions  are  taken  as  necessary. 

Activity  7 

Project 

The  project  is  responsible  for  ensuring  that  the  project’s  critical  computer  re¬ 
sources  are  tracked  and  corrective  actions  are  taken  as  necessary. 

124 


CMU/SEI-2002-TR-008 


Key 

Practice 


Classification  Notes 


Activity  8  Project  The  project  is  responsible  for  ensuring  that  the  project’s  software  schedule  is 

tracked  and  corrective  actions  are  taken  as  necessary. 

Activity  9  Project  The  project  is  responsible  for  ensuring  that  software  engineering  technical  ac¬ 

tivities  are  tracked  and  corrective  actions  are  taken  as  necessary. 

Activity  10  Project  The  project  is  responsible  for  ensuring  that  the  software  risks  associated  with 

cost,  resource,  schedule,  and  technical  aspects  of  the  project  are  tracked. 

Activity  1 1  Project  The  project  is  responsible  for  ensuring  that  actual  measurement  data  and  re¬ 

planning  data  for  the  software  project  are  recorded. 

Activity  12  Project  The  project  is  responsible  for  ensuring  that  the  software  engineering  group  con¬ 

ducts  periodic  internal  reviews  to  track  technical  progress,  plans,  performance, 
and  issues  against  the  software  development  plan. 

Activity  13  Project  The  project  is  responsible  for  ensuring  that  formal  reviews  to  address  the  ac¬ 

complishments  and  results  of  the  software  project  are  conducted  at  selected 
project  milestones  according  to  a  documented  procedure. 

Measurement  1  Project  The  project  is  responsible  for  ensuring  that  measurements  are  made  and  used  to 

determine  the  status  of  the  software  tracking  and  oversight  activities. 

Verification  1  Project  and  Both  the  organization  and  the  project  are  responsible  for  ensuring  that  the  ac- 
Organization  tivities  for  software  project  and  tracking  are  reviewed  with  senior  management 
on  a  periodic  basis. 

Verification  2  Project  The  project  is  responsible  for  ensuring  that  the  activities  for  software  project 

tracking  and  oversight  are  reviewed  with  the  project  manager  on  both  a  periodic 
and  event-driven  basis. 


Verification  3  Project  and  Both  the  organization  and  the  project  are  responsible  for  ensuring  that  the  soft- 

Organization  ware  quality  assurance  group  reviews  and/or  audits  the  activities  and  work 

products  for  software  project  tracking  and  oversight  and  reports  the  results. 
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9.5  Key  Practice  Classification  for  Software  Quality 
Assurance  _ 


Key 

Practice 

Classification 

■■  '  . 

Commitment  1 

Project  and 
Organization 

Both  the  organization  and  the  project  are  responsible  for  ensuring  that  the  pro¬ 
ject  follows  a  written  organizational  policy  for  implementing  software  quality 
assurance  (SQA). 

Ability  1 

Project  and 
Organization 

Both  the  organization  and  the  project  are  responsible  for  ensuring  that  a  group 
that  is  responsible  for  coordinating  and  implementing  SQA  for  the  project  (i.e., 
the  SQA  group)  exists. 

Ability  2 

Project  and 
Organization 

Both  the  organization  and  the  project  are  responsible  for  ensuring  that  adequate 
resources  and  funding  are  provided  for  performing  the  SQA  activities. 

Ability  3 

Project  and 
Organization 

Both  the  organization  and  the  project  are  responsible  for  ensuring  that  members 
of  the  SQA  group  are  trained  to  perform  their  SQA  activities. 

Ability  4 

Project 

The  project  is  responsible  for  ensuring  that  members  of  the  software  project 
receive  orientation  on  the  role,  responsibilities,  authority,  and  value  of  the  SQA 
group. 

Activity  1 

Project 

The  project  is  responsible  for  ensuring  that  an  SQA  plan  is  prepared  for  the 
software  project  according  to  a  documented  procedure. 

Activity  2 

Project 

The  project  is  responsible  for  ensuring  that  the  SQA  group’s  activities  are  per¬ 
formed  in  accordance  with  the  SQA  plan. 

Activity  3 

Project 

The  project  is  responsible  for  ensuring  that  the  SQA  group  participates  in  the 
preparation  and  review  of  the  project’s  software  development  plan,  standards, 
and  procedures. 

Activity  4 

Project 

The  project  is  responsible  for  ensuring  that  the  SQA  group  reviews  the  software 
engineering  activities  to  verify  compliance. 

Activity  5 

Project 

The  project  is  responsible  for  ensuring  that  the  SQA  group  audits  designated 
software  work  products  to  verify  compliance. 

Activity  6 

Project 

The  project  is  responsible  for  ensuring  that  the  SQA  group  periodically  reports 
the  results  of  its  activities  to  the  software  engineering  group. 

Activity  7 

Project 

The  project  is  responsible  for  ensuring  that  deviations  identified  in  the  software 
activities  and  software  work  products  are  documented  and  handled  according  to 
a  documented  procedure. 

Activity  8 

Project 

The  project  is  responsible  for  ensuring  that  the  SQA  group  conducts  periodic 
reviews  of  its  activities  and  findings  with  the  customer’s  SQA  personnel,  as 
appropriate. 

Measurement  1 

Project 

The  project  is  responsible  for  ensuring  that  measurements  are  made  and  used  to 
determine  the  cost  and  schedule  status  of  the  SQA  activities. 
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Key 

Practice 

Classification 

Notes 

Verification  1 

Project  and 
Organization 

Both  the  organization  and  the  project  are  responsible  for  ensuring  that  the  SQA 
activities  are  reviewed  with  senior  management  on  a  periodic  basis. 

Verification  2 

Project 

The  project  is  responsible  for  ensuring  that  the  SQA  activities  are  reviewed  with 
the  project  manager  on  both  a  periodic  and  event- driven  basis. 

Verification  3 

Project 

The  project  is  responsible  for  ensuring  that  experts  independent  of  the  SQA 
group  periodically  review  the  activities  and  software  work  products  of  the  pro¬ 
ject’s  SQA  group. 
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9.6  Key  Practice  Classification  for  Software  Configu¬ 
ration  Management  _ _ _ _ 


Key 

Practice 

. . 

Classification 

Notes  £•:  /-v  ‘  • 

;V.r  v; .  ::p ' '-S':  '-] ■  ...  .■  ’  "■■■■  J\.  ’  i -v ’ 

Commitment  1 

Project  and 
Organization 

Both  the  organization  and  the  project  are  responsible  for  ensuring  that  the  pro¬ 
ject  follows  a  written  organizational  policy  for  implementing  software  configu¬ 
ration  management  (SCM). 

Ability  1 

Project 

The  project  is  responsible  for  ensuring  that  a  board  having  the  authority  for 
managing  the  project’s  software  baselines  (i.e.,  a  software  configuration  control 
board — SCCB)  exists  or  is  established. 

Ability  2 

Project 

The  project  is  responsible  for  ensuring  that  a  group  that  is  responsible  for  coor¬ 
dinating  and  implementing  SCM  for  the  project  (i.e.,  the  SCM  group)  exists. 

Ability  3 

Project  and 
Organization 

Both  the  organization  and  the  project  are  responsible  for  ensuring  that  adequate 
resources  and  funding  are  provided  for  performing  the  SCM  activities. 

Ability  4 

Project  and 
Organization 

Both  the  organization  and  the  project  are  responsible  for  ensuring  that  members 
of  the  SCM  group  are  trained  in  the  objectives,  procedures,  and  methods  for 
performing  their  SCM  activities. 

Ability  5 

Project 

The  project  is  responsible  for  ensuring  that  members  of  the  software  engineering 
group  and  other  software-related  groups  are  trained  to  perform  their  SCM  activi¬ 
ties. 

Activity  1 

Project 

The  project  is  responsible  for  ensuring  that  A  SCM  plan  is  prepared  for  each 
software  project  according  to  a  documented  procedure. 

Activity  2 

Project 

The  project  is  responsible  for  ensuring  that  a  documented  and  approved  SCM 
plan  is  used  as  the  basis  for  performing  the  SCM  activities. 

Activity  3 

Project 

The  project  is  responsible  for  ensuring  that  a  configuration  management  library 
system  is  established  as  a  repository  for  the  software  baselines. 

Activity  4 

Project 

The  project  is  responsible  for  ensuring  that  the  software  work  products  to  be 
placed  under  configuration  management  are  identified. 

Activity  5 

Project 

The  project  is  responsible  for  ensuring  that  change  requests  and  problem  reports 
for  all  configuration  items/units  are  initiated,  recorded,  reviewed,  approved,  and 
tracked  according  to  a  documented  procedure. 

Activity  6 

Project 

The  project  is  responsible  for  ensuring  that  changes  to  baselines  are  controlled 
according  to  a  documented  procedure. 

Activity  7 

Project 

The  project  is  responsible  for  ensuring  that  products  from  the  software  baseline 
library  are  created  and  their  release  is  controlled  according  to  a  documented 
procedure. 

Activity  8 

Project 

The  project  is  responsible  for  ensuring  that  the  status  of  configuration 
items/units  is  recorded  according  to  a  documented  procedure. 
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Key 

Practice 

Classification 

Notes 

Activity  9 

Project 

The  project  is  responsible  for  ensuring  that  standard  reports  documenting  the 

SCM  activities  and  the  contents  of  the  software  baseline  are  developed  and 
made  available  to  affected  groups  and  individuals. 

Activity  10 

Project 

The  project  is  responsible  for  ensuring  that  software  baseline  audits  are  con¬ 
ducted  according  to  a  documented  procedure. 

Measurement  1 

Project 

The  project  is  responsible  for  ensuring  that  measurements  are  made  and  used  to 
determine  the  status  of  the  SCM  activities. 

Verification  1 

Project  and 
Organization 

Both  the  organization  and  the  project  are  responsible  for  ensuring  that  the  SCM 
activities  are  reviewed  with  senior  management  on  a  periodic  basis. 

Verification  2 

Project 

The  project  is  responsible  for  ensuring  that  the  SCM  activities  are  reviewed  with 
the  project  manager  on  both  a  periodic  and  event-driven  basis. 

Verification  3 

Project 

The  project  is  responsible  for  ensuring  that  the  SCM  group  periodically  audits 
software  baselines  to  verify  that  they  conform  to  the  documentation  that  defines 
them. 

Verification  4 

Project  and 
Organization 

Both  the  organization  and  the  project  are  responsible  for  ensuring  that  the  soft¬ 
ware  quality  assurance  group  reviews  and/or  audits  the  activities  and  work  prod¬ 
ucts  for  SCM  and  reports  the  results. 
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9.7  Key  Practice  Classification  for  Organization  Proc¬ 
ess  Focus  _ 


Key 

Practice 

Classification 

'  •  ••  $ 

.Notes  '■  : 

Commitment  1 

Organization 

The  organization  is  responsible  for  ensuring  that  the  organization  follows  a  writ¬ 
ten  organizational  policy  for  coordinating  software  process  development  and 
improvement  activities  across  the  organization. 

Commitment  2 

Organization 

The  organization  is  responsible  for  ensuring  that  senior  management  sponsors 
the  organization’s  activities  for  software  process  development  and  improvement. 

Commitment  3 

Organization 

The  organization  is  responsible  for  ensuring  that  senior  management  oversees 
the  organization’s  activities  for  software  process  development  and  improvement. 

Ability  1 

Organization 

The  organization  is  responsible  for  ensuring  that  a  group  that  is  responsible  for 
the  organization’s  software  process  activities  exists. 

Ability  2 

Organization 

The  organization  is  responsible  for  ensuring  that  adequate  resources  and  funding 
are  provided  for  the  organization’s  software  process  activities. 

Ability  3 

Organization 

The  organization  is  responsible  for  ensuring  that  members  of  the  group  respon¬ 
sible  for  the  organization’s  software  process  activities  receive  required  training 
to  perform  these  activities. 

Ability  4 

Organization 

The  organization  is  responsible  for  ensuring  that  members  of  the  software  engi¬ 
neering  group  and  other  software-related  groups  receive  orientation  on  the  or¬ 
ganization’s  software  process  activities  and  their  roles  in  those  activities. 

Activity  1 

Organization 

The  organization  is  responsible  for  ensuring  that  the  software  process  is  assessed 
periodically,  and  action  plans  are  developed  to  address  the  assessment  findings. 

Activity  2 

Organization 

The  organization  is  responsible  for  ensuring  that  the  organization  develops  and 
maintains  a  plan  for  its  software  process  development  and  improvement  activi¬ 
ties. 

Activity  3 

Organization 

The  organization  is  responsible  for  ensuring  that  the  organization’s  and  projects’ 
activities  for  developing  and  improving  their  software  processes  are  coordinated 
at  the  organization  level. 

Activity  4 

Organization 

The  organization  is  responsible  for  ensuring  that  the  use  of  the  organization’s 
software  process  database  is  coordinated  at  the  organizational  level. 

Activity  5 

Organization 

The  organization  is  responsible  for  ensuring  that  new  processes,  methods,  and 
tools  in  limited  use  in  the  organization  are  monitored,  evaluated,  and,  where 
appropriate,  transferred  to  other  parts  of  the  organization. 

Activity  6 

Organization 

The  organization  is  responsible  for  ensuring  that  training  for  the  organization’s 
and  projects’  software  processes  is  coordinated  across  the  organization. 
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Key  Classification  Notes 

Practice 

Activity  7  Project  and  Both  the  organization  and  the  project  are  responsible  for  ensuring  that  the 

Organization  groups  involved  in  implementing  the  software  processes  are  informed  of  the 
organization’s  and  projects’  activities  for  software  process  development  and 
improvement. 

Measurement  1  Organization  The  organization  is  responsible  for  ensuring  that  measurements  are  made  and 

used  to  determine  the  status  of  the  organization’s  process  development  and  im¬ 
provement  activities. 

Verification  1  Organization  The  organization  is  responsible  for  ensuring  that  the  activities  for  software  proc¬ 

ess  development  and  improvement  are  reviewed  with  senior  management  on  a 
periodic  basis. 
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9.8  Key  Practice  Classification  for  Organization  Proc¬ 
ess  Definition 


Key 

Practice 

Classification 

Notes  •/  ■ 

Commitment  I 

Organization 

The  organization  is  responsible  for  ensuring  that  the  organization  follows  a  writ¬ 
ten  policy  for  developing  and  maintaining  a  standard  software  process  and  re¬ 
lated  process  assets. 

Ability  1 

Organization 

The  organization  is  responsible  for  ensuring  that  adequate  resources  and  funding 
are  provided  for  developing  and  maintaining  the  organization’s  standard  soft¬ 
ware  process  and  related  process  assets. 

Ability  2 

Organization 

The  organization  is  responsible  for  ensuring  that  the  individuals  who  develop 
and  maintain  the  organization’s  standard  software  process  and  related  process 
assets  receive  required  training  to  perform  these  activities. 

Activity  1 

Organization 

The  organization  is  responsible  for  ensuring  that  the  organization’s  standard 
software  process  is  developed  and  maintained  according  to  a  documented  proce¬ 
dure. 

Activity  2 

Organization 

The  organization  is  responsible  for  ensuring  that  the  organization’s  standard 
software  process  is  documented  according  to  established  organization  standards. 

Activity  3 

Organization 

The  organization  is  responsible  for  ensuring  that  the  descriptions  of  software  life 
cycles  that  are  approved  for  use  by  the  projects  are  documented  and  maintained. 

Activity  4 

Organization 

The  organization  is  responsible  for  ensuring  that  guidelines  and  criteria  for  the 
projects’  tailoring  of  the  organization’s  standard  software  process  are  developed 
and  maintained. 

Activity  5 

Organization 

The  organization  is  responsible  for  ensuring  that  the  organization’s  software 
process  database  is  established  and  maintained. 

Activity  6 

Organization 

The  organization  is  responsible  for  ensuring  that  a  library  of  software  process- 
related  documentation  is  established  and  maintained. 

Measurement  1 

Organization 

The  organization  is  responsible  for  ensuring  that  measurements  are  made  and 
used  to  determine  the  status  of  the  organization’s  process  definition  activities. 

Verification  1 

Organization 

The  organization  is  responsible  for  ensuring  that  the  software  quality  assurance 
group  reviews  and/or  audits  the  organization’s  activities  and  work  products  for 
developing  and  maintaining  the  organization’s  standard  software  process  and 
related  process  assets  and  reports  the  results. 
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9.9  Key  Practice  Classification  for  Training  Program 


_ K _ 

Key 

Practice 

Classification 

Notes  : 

Commitment  1 

Organization 

The  organization  is  responsible  for  ensuring  that  the  organization  follows  a  writ¬ 
ten  policy  for  meeting  its  training  needs. 

Ability  1 

Organization 

The  organization  is  responsible  for  ensuring  that  a  group  responsible  for  the 
training  needs  of  the  organization  exists. 

Ability  2 

Organization 
and  Project 

Both  the  organization  and  the  project  are  responsible  for  providing  adequate 
resources  and  funding  to  implement  the  organizational  and  the  project’s  training 
plans,  respectively. 

Ability  3 

Organization 

The  organization  is  responsible  for  ensuring  that  members  of  the  training  group 
have  the  necessary  skills  and  knowledge  to  perform  their  training  activities. 

Ability  4 

Organization 

The  organization  is  responsible  for  ensuring  that  software  managers  receive 
orientation  on  the  training  program. 

Activity  1 

Project 

The  project  is  responsible  for  developing  and  maintaining  a  training  plan  that 
specifies  its  training  needs. 

Activity  2 

Organization 

The  organization  is  responsible  for  ensuring  that  the  organization’s  training  plan 
is  developed  and  revised  according  to  a  documented  procedure. 

Activity  3 

Organization 

The  organization  is  responsible  for  ensuring  that  the  training  for  the  organization 
is  performed  in  accordance  with  the  organization’s  training  plan. 

Activity  4 

Organization 

The  organization  is  responsible  for  ensuring  that  training  courses  prepared  at  the 
organization  level  are  developed  and  maintained  according  to  organization  stan¬ 
dards. 

Activity  5 

Organization 
and  Project 

The  organization  is  responsible  for  ensuring  that  a  waiver  procedure  is  estab¬ 
lished,  and  the  project  is  responsible  for  using  the  waiver  procedure  to  determine 
whether  or  not  individuals  already  possess  the  knowledge  and  skills  required  to 
perform  their  designated  roles. 

Activity  6 

Organization 

The  organization  is  responsible  for  ensuring  that  records  of  training  are  main¬ 
tained. 

Measurement  1 

Organization 

The  organization  is  responsible  for  ensuring  that  measurements  are  made  and 
used  to  determine  the  status  of  training  program  activities. 

Measurement  2 

Organization 

The  organization  is  responsible  for  ensuring  that  measurements  are  made  and 
used  to  determine  the  quality  of  the  training  program. 

Verification  1 

Organization 

The  organization  is  responsible  for  ensuring  that  the  training  program  activities 
are  reviewed  with  senior  management  on  a  periodic  basis. 

Verification  2 

Organization 

The  organization  is  responsible  for  ensuring  that  the  training  program  is  evalu¬ 
ated  on  a  periodic  basis  for  consistency  with,  and  relevance  to,  the  organiza¬ 
tion’s  needs. 
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Key 

Practice 

Classification 

Notes 

Verification  3 

Organization 

The  organization  is  responsible  for  ensuring  that  the  training  program  activities 
and  work  products  are  reviewed  and/or  audited,  and  that  the  results  are  reported. 
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9.10  Key  Practice  Classification  for  Integrated  Soft- 
ware  Management  _ _ 


Key 

Practice 

Classification 

Notes  . 

Commitment  1 

Project  and 
Organization 

Both  the  organization  and  the  project  are  responsible  for  ensuring  that  the  pro¬ 
ject  follows  a  written  organizational  policy  requiring  that  the  software  project  is 
planned  and  managed  using  the  organization’s  standard  software  process  and 
related  process  assets. 

Ability  1 

Project  and 
Organization 

Both  the  organization  and  the  project  are  responsible  for  ensuring  that  adequate 
resources  and  funding  are  provided  for  individuals  developing  the  project’s 
defined  process. 

Ability  2 

Project  and 
Organization 

Both  the  organization  and  the  project  are  responsible  for  ensuring  that  the  indi¬ 
viduals  responsible  for  developing  the  project’s  defined  software  process  re¬ 
ceive  required  training  in  how  to  tailor  the  organization’s  standard  software 
process  and  use  the  related  process  assets. 

Ability  3 

Project  and 
Organization 

Both  the  project  and  the  organization  are  responsible  for  ensuring  that  the  pro¬ 
ject’s  software  managers  receive  required  training  in  managing  the  technical, 
administrative,  and  personnel  aspects  of  the  software  project  based  on  the  pro¬ 
ject’s  defined  software  process. 

Activity  1 

Project 

The  project  is  responsible  for  ensuring  that  the  project’s  defined  software  proc¬ 
ess  is  developed  by  tailoring  the  organization’s  standard  software  process,  ac¬ 
cording  to  a  documented  procedure. 

Activity  2 

Project 

The  project  is  responsible  for  ensuring  that  each  project’s  defined  software 
process  is  revised  according  to  a  documented  procedure. 

Activity  3 

Project 

The  project  is  responsible  for  ensuring  that  the  project’s  software  development 
plan,  which  describes  the  use  of  the  project’s  defined  software  process,  is  de¬ 
veloped  and  revised  according  to  a  documented  procedure.  j 

Activity  4 

Project 

The  project  is  responsible  for  ensuring  that  the  software  project  is  managed  in 
accordance  with  the  project’s  defined  process. 

Activity  5 

Project 

The  project  is  responsible  for  ensuring  that  the  organization’s  software  process 
database  is  used  for  software  planning  and  estimating. 

Activity  6 

Project 

The  project  is  responsible  for  ensuring  that  the  size  of  the  software  work  prod¬ 
ucts  (or  size  of  changes  to  the  software  work  products)  is  managed  according  to 
a  documented  procedure. 

Activity  7 

Project 

The  project  is  responsible  for  ensuring  that  the  project’s  software  effort  and 
costs  are  managed  according  to  a  documented  procedure. 

Activity  8 

Project 

The  project  is  responsible  for  ensuring  that  the  project’s  critical  computer  re¬ 
sources  are  managed  according  to  a  documented  procedure. 

Activity  9 

Project 

The  project  is  responsible  for  ensuring  that  the  critical  dependencies  and  critical 
paths  of  the  project’s  software  schedule  are  managed  according  to  a  docu¬ 
mented  procedure. 
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Activity  10 

Project 

The  project  is  responsible  for  ensuring  that  the  project's  software  risks  are  iden¬ 
tified,  assessed,  documented,  and  managed  according  to  a  documented  proce¬ 
dure. 

Activity  1 1 

Project 

The  project  is  responsible  for  ensuring  that  reviews  of  the  software  project  are 
periodically  performed  to  determine  the  actions  needed  to  bring  the  software 
project’s  performance  and  results  in  line  with  the  current  and  projected  needs  of 
the  business,  customer,  and  end  users,  as  appropriate. 

Measurement  1 

Project 

The  project  is  responsible  for  ensuring  that  measurements  are  made  and  used  to 
determine  the  effectiveness  of  the  integrated  software  management  activities. 

Verification  1 

Project  and 
Organization 

Both  the  organization  and  the  project  are  responsible  for  ensuring  that  the  ac¬ 
tivities  for  managing  the  software  project  are  reviewed  with  senior  management 
on  a  periodic  basis. 

Verification  2 

Project 

The  project  is  responsible  for  ensuring  that  the  activities  for  managing  the  soft¬ 
ware  project  are  reviewed  with  the  project  manager  on  both  a  periodic  and 
event-driven  basis. 

Verification  3 

Project  and 
Organization 

Both  the  organization  and  the  project  are  responsible  for  ensuring  that  the  soft¬ 
ware  quality  assurance  group  reviews  and/or  audits  the  activities  and  work 
products  for  managing  the  software  project  and  reports  the  results. 
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9.1 1  Key  Practice  Classification  for  Software  Product 
Engineering  _ 


Key 

Practice 

Classification 

Notes 

Commitment  1 

Project  and 
Organization 

Both  the  organization  and  the  project  are  responsible  for  ensuring  that  the 
project  follows  a  written  organizational  policy  for  performing  the  software 
engineering  activities. 

Ability  1 

Project  and 
Organization 

Both  the  organization  and  the  project  are  responsible  for  ensuring  that  ade¬ 
quate  resources  and  funding  are  provided  for  performing  software  engineering 
tasks. 

Ability  2 

Project  and 
Organization 

The  project  and  organization  are  responsible  for  ensuring  that  members  of  the 
software  engineering  technical  staff  receive  required  training  to  perform  their 
technical  assignments. 

Ability  3 

Project 

The  project  is  responsible  for  ensuring  that  members  of  the  software  engineer¬ 
ing  technical  staff  receive  orientation  in  related  software  engineering  disci¬ 
plines. 

Ability  4 

Project 

The  project  is  responsible  for  ensuring  that  the  project  manager  and  all  soft¬ 
ware  managers  receive  orientation  in  the  technical  aspects  of  the  software 
project. 

Activity  1 

Project 

The  project  is  responsible  for  ensuring  that  appropriate  software  engineering 
methods  and  tools  are  integrated  into  the  project’s  defined  software  process. 

Activity  2 

Project 

The  project  is  responsible  for  ensuring  that  the  software  requirements  are  de¬ 
veloped,  maintained,  documented,  and  verified  by  systematically  analyzing 
the  allocated  requirements  according  to  the  project’s  defined  software  process. 

Activity  3 

Project 

The  project  is  responsible  for  ensuring  that  the  software  design  is  developed, 
maintained,  documented,  and  verified,  according  to  the  project’s  defined  soft¬ 
ware  process,  to  accommodate  the  software  requirements  and  to  form  the 
framework  for  coding. 

Activity  4 

Project 

The  project  is  responsible  for  ensuring  that  the  software  code  is  developed, 
maintained,  documented,  and  verified,  according  to  the  project’s  defined  soft¬ 
ware  process,  to  implement  the  software  requirements  and  software  design. 

Activity  5 

Project 

The  project  is  responsible  for  ensuring  that  software  testing  is  performed  ac¬ 
cording  to  the  project’s  defined  software  process. 

Activity  6 

Project 

The  project  is  responsible  for  ensuring  that  integration  testing  of  the  software 
is  planned  and  performed  according  to  the  project’s  defined  software  process. 

Activity  7 

Project 

The  project  is  responsible  for  ensuring  that  system  and  acceptance  testing  of 
the  software  are  planned  and  performed  to  demonstrate  that  the  software  satis¬ 
fies  its  requirements. 

Activity  8 

Project 

The  project  is  responsible  for  ensuring  that  the  documentation  that  will  be 
used  to  operate  and  maintain  the  software  is  developed  and  maintained  accord¬ 
ing  to  the  project’s  defined  software  process. 
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Activity  9 

Project 

The  project  is  responsible  for  ensuring  that  data  on  defects  identified  in  peer 
reviews  and  testing  are  collected  and  analyzed  according  to  the  project  s  de¬ 
fined  software  process. 

Activity  10 

Project 

The  project  is  responsible  for  ensuring  that  consistency  is  maintained  across 
software  work  products,  including  the  software  plans,  process  descriptions, 
allocated  requirements,  software  requirements,  software  design,  code,  test 
plans,  and  test  procedures. 

Measurement  1 

Project 

The  project  is  responsible  for  ensuring  that  measurements  are  made  and  used 
to  determine  the  functionality  and  quality  of  the  software  products. 

Measurement  2 

Project 

The  project  is  responsible  for  ensuring  that  measurements  are  made  and  used 
to  determine  the  status  of  the  software  product  engineering  activities. 

Verification  1 

Project  and 
Organization 

Both  the  organization  and  the  project  are  responsible  for  ensuring  that  the 
activities  for  software  product  engineering  are  reviewed  with  senior  manage- 
ment  on  a  periodic  basis. 

Verification  2 

Project 

The  project  is  responsible  for  ensuring  that  the  activities  for  software  product 
engineering  are  reviewed  with  the  project  manager  on  both  a  periodic  and 
event-driven  basis. 

Verification  3 

Project  and 
Organization 

Both  the  organization  and  the  project  are  responsible  for  ensuring  that  the 
software  quality  assurance  group  reviews  and/or  audits  the  activities  and  work 
products  for  software  product  engineering  and  reports  the  results. 
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9.12  Key  Practice  Classification  for  Intergroup  Coor¬ 
dination  _ 


Key 

Practice 

Classification 

Notes 

Commitment  1 

Project  and 
Organization 

Both  the  organization  and  the  project  are  responsible  for  ensuring  that  the 
project  follows  a  written  organizational  policy  for  performing  Intergroup  coor¬ 
dination  activities. 

Ability  1 

Project  and 
Organization 

Both  the  organization  and  the  project  are  responsible  for  ensuring  adequate 
resources  and  funding  are  provided  for  coordinating  software  engineering 
activities  with  other  engineering  groups. 

Ability  2 

Project 

The  project  is  responsible  for  ensuring  that  the  support  tools  used  by  the  dif¬ 
ferent  engineering  groups  are  compatible  to  enable  effective  communication 
and  coordination. 

Ability  3 

Project  and 
Organization 

Both  the  organization  and  the  project  are  responsible  for  ensuring  that  all  man¬ 
agers  in  the  organization  receive  required  training  in  teamwork. 

Ability  4 

Project 

The  project  is  responsible  for  ensuring  that  all  task  leaders  in  each  engineering 
group  receive  orientation  in  the  processes,  methods,  and  standards  used  by  the 
other  engineering  groups. 

Ability  5 

Project 

The  project  is  responsible  for  ensuring  that  the  members  of  the  engineering 
groups  receive  orientation  in  working  as  a  team. 

Activity  1 

Project 

The  project  is  responsible  for  ensuring  that  the  software  engineering  group  and 
the  other  engineering  groups  participate  with  the  customer  and  end  users,  as 
appropriate,  to  establish  the  system  requirements. 

Activity  2 

Project 

The  project  is  responsible  for  ensuring  that  representatives  of  the  project’s 
software  engineering  group  work  with  representatives  of  the  other  engineering 
groups  to  monitor  and  coordinate  technical  activities  and  resolve  technical 
issues. 

Activity  3 

Project 

The  project  is  responsible  for  ensuring  that  a  documented  plan  is  used  to 
communicate  intergroup  commitments  and  to  coordinate  and  track  the  work 
performed. 

Activity  4 

Project 

The  project  is  responsible  for  ensuring  that  the  critical  dependencies  between 
engineering  groups  are  identified,  negotiated,  and  tracked  according  to  a 
documented  procedure. 

Activity  5 

Project 

The  project  is  responsible  for  ensuring  that  the  work  products  produced  as 
input  to  other  engineering  groups  are  reviewed  by  representatives  of  the  re¬ 
ceiving  groups. 

Activity  6 

Project 

The  project  is  responsible  for  ensuring  that  the  intergroup  issues  not  resolvable 
by  the  individual  representatives  of  the  project  engineering  groups  are  handled 
according  to  a  documented  procedure. 

Activity  7 

Project 

The  project  is  responsible  for  ensuring  that  the  representatives  of  the  project 
engineering  groups  conduct  periodic  technical  reviews  and  interchanges. 
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Key 

Practice 

Notes 

Measurement  1 

Project 

The  project  is  responsible  for  ensuring  that  measurements  are  made  and  used 
to  determine  the  status  of  the  intergroup  coordination  activities. 

Verification  1 

Project  and 
Organization 

Both  the  organization  and  the  project  are  responsible  for  ensuring  that  the 
activities  for  intergroup  coordination  are  reviewed  with  senior  management  on 
a  periodic  basis. 

Verification  2 

Project 

The  project  is  responsible  for  ensuring  that  the  activities  for  intergroup  coordi¬ 
nation  are  reviewed  with  the  project  manager  on  both  a  periodic  and  event- 
driven  basis. 

Verification  3 

Project  and 
Organization 

Both  the  organization  and  the  project  are  responsible  for  ensuring  that  the 
software  quality  assurance  group  reviews  and/or  audits  the  activities  and  work 
products  for  intergroup  coordination  and  reports  the  results. 
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9.13  Key  Practice  Classification  for  Peer  Review 


_ 

Key 

Practice 

Classification 

Notes 

Commitment  1 

Project  and 
Organization 

Both  the  organization  and  the  project  are  responsible  for  written  policies  for 
performing  peer  reviews. 

Ability  1 

Project  and 
Organization 

Both  the  organization  and  the  project  are  responsible  for  ensuring  that  ade¬ 
quate  resources  and  funding  are  provided  for  performing  peer  reviews  on  each 
software  work  product  to  be  reviewed. 

Ability  2 

Project 

Both  the  organization  and  the  project  are  responsible  for  ensuring  that  peer 
review  leaders  receive  required  training  in  how  to  lead  peer  reviews. 

Ability  3 

Project  and 
Organization 

Both  the  organization  and  the  project  are  responsible  for  ensuring  that  the 
reviewers  who  participate  in  peer  reviews  receive  required  training  in  the 
objectives,  principles,  and  methods  of  peer  reviews. 

Activity  1 

Project 

The  project  is  responsible  for  ensuring  that  the  peer  reviews  are  planned,  and 
the  plans  are  documented. 

Activity  2 

Project 

The  project  is  responsible  for  ensuring  that  peer  reviews  are  performed  ac¬ 
cording  to  a  documented  procedure. 

Activity  3 

Project 

The  project  is  responsible  for  ensuring  that  data  on  the  conduct  and  results  of 
the  peer  reviews  are  recorded. 

Measurement  1 

Project 

The  project  is  responsible  for  ensuring  that  measurements  are  made  and  used 
to  determine  the  status  of  the  peer  review  activities. 

Verification  1 

Project  and 
Organization 

Both  the  organization  and  the  project  are  responsible  for  ensuring  that  the 
software  quality  assurance  group  reviews  and/or  audits  the  activities  and  work 
products  for  peer  reviews  and  reports  the  results. 
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9.14  Key  Practice  Classification  for  Quantitative 
Process  Management  _ 


Key 

Practice 

Classification 

Notes 

Commitment  1 

Project  and 
Organization 

Both  the  organization  and  the  project  are  responsible  for  ensuring  that  the  pro¬ 
ject  follows  a  written  organizational  policy  for  measuring  and  quantitatively 
controlling  the  performance  of  the  project’s  defined  software  process. 

Commitment  2 

Organization 

The  organization  is  responsible  for  ensuring  that  the  organization  follows  a  writ¬ 
ten  policy  for  analyzing  the  process  capability  of  the  organization’s  standard 
software  process. 

Ability  1 

Organization 

The  organization  is  responsible  for  ensuring  that  a  group  that  is  responsible  for 
coordinating  the  quantitative  process  management  activities  for  the  organization 
exists. 

Ability  2 

Project  and 
Organization 

Both  the  organization  and  the  project  are  responsible  for  ensuring  that  adequate 
resources  and  funding  are  provided  for  the  quantitative  process  management 
activities. 

Ability  3 

Project  and 
Organization 

Both  the  organization  and  the  project  are  responsible  for  ensuring  that  support 
exists  for  collecting,  recording,  and  analyzing  data  for  selected  process  and 
product  measurements. 

Ability  4 

Project  and 
Organization 

Both  the  organization  and  the  project  are  responsible  for  ensuring  that  the  indi¬ 
viduals  implementing  or  supporting  quantitative  process  management  receive 
required  training  to  perform  these  activities. 

Ability  5 

Project  and 
Organization 

Both  the  organization  and  the  project  are  responsible  for  ensuring  that  the  mem¬ 
bers  of  the  software  engineering  group  and  other  software-related  groups  receive 
orientation  on  the  goals  and  value  of  quantitative  process  management. 

Activity  1 

Project 

The  project  is  responsible  for  ensuring  that  the  software  project’s  plan  for  quan¬ 
titative  process  management  is  developed  according  to  a  documented  procedure. 

Activity  2 

Project 

The  project  is  responsible  for  ensuring  that  the  software  project’s  quantitative 
process  management  activities  are  performed  in  accordance  with  the  project’s 
quantitative  process  management  plan. 

Activity  3 

Project 

The  project  is  responsible  for  ensuring  that  the  strategy  for  the  data  collection 
and  the  quantitative  analyses  to  be  performed  are  determined  based  on  the  pro¬ 
ject’s  defined  software  process. 

Activity  4 

Project 

The  project  is  responsible  for  ensuring  that  the  measurement  data  used  to  control 
the  project’s  defined  software  process  quantitatively  are  collected  according  to  a 
documented  procedure. 

Activity  5 

Project 

The  project  is  responsible  for  ensuring  that  the  project’s  defined  software  proc¬ 
ess  is  analyzed  and  brought  under  quantitative  control  according  to  a  docu¬ 
mented  procedure. 
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Key 

Practice 

Classification 

Notes 

Activity  6 

Project 

The  project  is  responsible  for  ensuring  that  reports  documenting  the  results  of 
the  software  project’s  quantitative  process  management  activities  are  prepared 
and  distributed. 

Activity  7 

Project  and 
Organization 

Both  the  organization  and  the  project  are  responsible  for  ensuring  that  the  proc¬ 
ess  capability  baseline  for  the  organization’s  standard  software  process  is  estab¬ 
lished  and  maintained  according  to  a  documented  procedure. 

Measurement  1 

Project  and 
Organization 

Both  the  organization  and  the  project  are  responsible  for  ensuring  that  measure¬ 
ments  are  made  and  used  to  determine  the  status  of  the  activities  for  quantitative 
process  management. 

Verification  1 

Project  and 
Organization 

Both  the  organization  and  the  project  are  responsible  for  ensuring  that  the  activi¬ 
ties  for  software  quality  management  are  reviewed  with  senior  management  on  a 
periodic  basis. 

Verification  2 

Project 

The  software  project’s  activities  for  quantitative  process  management  are  re¬ 
viewed  with  the  project  manager  on  both  a  periodic  and  event-driven  basis. 

Verification  3 

Project  and 
Organization 

Both  the  organization  and  the  project  are  responsible  for  ensu 
ware  quality  assurance  group  reviews  and/or  audits  the  activi! 
products  for  quantitative  process  management  and  reports  the 

ring  that  the  soft- 
ties  and  work 
results. 
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9.15  Key  Practice  Classification  for  Software  Quality 
Management  _ 


Key 

Practice 

Classification 

Notes  ' 

Commitment  1 

Project  and 
Organization 

Both  the  project  and  the  organization  are  responsible  for  ensuring  that  the  pro¬ 
ject  follows  a  written  organizational  policy  for  managing  software  quality. 

Ability  1 

Project  and 
Organization 

Both  the  project  and  the  organization  are  responsible  for  ensuring  that  adequate 
resources  and  funding  are  provided  for  managing  the  quality  of  the  software 
products. 

Ability  2 

Project  and 
Organization 

Both  the  project  and  the  organization  are  responsible  for  ensuring  that  the  indi¬ 
viduals  implementing  and  supporting  software  quality  management  receive 
required  training  to  perform  their  activities. 

Ability  3 

Project  and 
Organization 

Both  the  project  and  the  organization  are  responsible  for  ensuring  that  the  mem¬ 
bers  of  the  software  engineering  group  and  other  software-related  groups  receive 
required  training  in  software  quality  management. 

Activity  1 

Project 

The  project  is  responsible  for  ensuring  that  the  project’s  software  quality  plan  is 
developed  and  maintained  according  to  a  documented  procedure. 

Activity  2 

Project 

The  project  is  responsible  for  ensuring  that  the  project’s  software  quality  plan  is 
the  basis  for  the  project’s  activities  for  software  quality  management. 

Activity  3 

Project 

The  project  is  responsible  for  ensuring  that  the  project’s  quantitative  quality 
goals  for  the  software  products  are  defined,  monitored,  and  revised  throughout 
the  software  life  cycle. 

Activity  4 

Project 

The  project  is  responsible  for  ensuring  that  the  quality  of  the  project’s  software 
products  is  measured,  analyzed,  and  compared  to  the  products’  quantitative 
quality  goals  on  an  event-driven  basis. 

Activity  5 

Project 

The  project  is  responsible  for  ensuring  that  the  software  project’s  quantitative 
quality  goals  for  the  products  are  allocated  appropriately  to  the  subcontractors 
delivering  software  products  to  the  project. 

Project 

The  project  is  responsible  for  ensuring  that  measurements  are  made  and  used  to 
determine  the  status  of  the  software  quality  management  activities. 

Verification  I 

Project  and 
Organization 

Both  the  project  and  the  organization  are  responsible  for  ensuring  that  the  activi¬ 
ties  for  software  quality  management  are  reviewed  with  senior  management  on  a 
periodic  basis. 

Verification  2 

Project 

The  project  is  responsible  for  ensuring  that  the  activities  for  software  quality 
management  are  reviewed  with  the  project  manager  on  both  a  periodic  and 
event-driven  basis. 

Verification  3 

Project  and 
Organization 

Both  the  project  and  the  organization  are  responsible  for  ensuring  that  the  soft¬ 
ware  quality  assurance  group  reviews  and/or  audits  the  activities  and  work 
products  for  software  quality  management  and  reports  the  results. 
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9.16  Key  Practice  Classification  for  Defect  Prevention 


_  + 

Key 

Practice 

Classification 

Notes 

Commitment  1 

Organization 

The  organization  is  responsible  for  ensuring  that  the  organization  follows  a  writ¬ 
ten  policy  for  defect  prevention  activities. 

Commitment  2 

Project  and 
Organization 

Both  the  organization  and  the  project  are  responsible  for  ensuring  that  the  pro¬ 
ject  follows  a  written  organizational  policy  for  defect  prevention  activities. 

Ability  1 

Organization 

The  organization  is  responsible  for  ensuring  that  an  organization-level  team  to 
coordinate  defect  prevention  activities  exists. 

Ability  2 

Project 

The  project  is  responsible  for  ensuring  that  a  team  to  coordinate  defect  preven¬ 
tion  activities  for  the  software  project  exists. 

Ability  3 

Project  and 
Organization 

Both  the  organization  and  the  project  are  responsible  for  ensuring  that  adequate 
resources  and  funding  are  provided  for  defect  prevention  activities  at  the  project 
and  organization  levels. 

Ability  4 

Project  and 
Organization 

Both  the  organization  and  the  project  are  responsible  for  ensuring  that  members 
of  the  software  engineering  group  and  other  software-related  groups  receive 
required  training  to  perform  their  defect  prevention  activities. 

Activity  1 

Project 

The  project  is  responsible  for  ensuring  that  the  software  project  develops  and 
maintains  a  plan  for  its  defect  prevention  activities. 

Activity  2 

Project 

The  project  is  responsible  for  ensuring  that  at  the  beginning  of  a  software  task, 
the  members  of  the  team  performing  the  task  meet  to  prepare  for  the  activities  of 
that  task  and  the  related  defect  prevention  activities. 

Activity  3 

Project 

The  project  is  responsible  for  ensuring  that  causal  analysis  meetings  are  con¬ 
ducted  according  to  a  documented  procedure. 

Activity  4 

Project 

The  project  is  responsible  for  ensuring  that  each  of  the  teams  assigned  to  coor¬ 
dinate  defect  prevention  activities  meets  on  a  periodic  basis  to  review  and  coor¬ 
dinate  implementation  of  action  proposals  from  the  causal  analysis  meetings. 

Note:  For  this  key  practice,  the  SW-CMM  elaborates,  “The  teams  involved  may 
be  at  the  organization  or  project  level.”  For  this  technical  report,  the  project 
level  was  chosen. 

Activity  5 

Project 

The  project  is  responsible  for  ensuring  that  defect  prevention  data  are  docu¬ 
mented  and  tracked  across  the  teams  coordinating  defect  prevention  activities. 
Note:  For  this  key  practice,  the  SW-CMM  is  ambiguous  about  where  this  re¬ 
sponsibility  lies.  For  this  technical  report,  the  project  level  was  chosen. 

Activity  6 

Organization 

The  organization  is  responsible  for  ensuring  that  revisions  to  the  organization’s 
standard  software  process  resulting  from  defect  prevention  actions  are  incorpo¬ 
rated  according  to  a  documented  procedure. 

Activity  7 

Project 

The  project  is  responsible  for  ensuring  that  revisions  to  the  project’s  defined 
software  process  resulting  from  defect  prevention  actions  are  incorporated  ac¬ 
cording  to  a  documented  procedure. 
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Key 

Practice 

Classification 

Notes 

Activity  8 

Project  and 
Organization 

Both  the  organization  and  the  project  are  responsible  for  ensuring  that  members 
of  the  software  engineering  group  and  software-related  groups  receive  feedback 
on  the  status  and  results  of  the  organization’s  and  project’s  defect  prevention 
activities  on  a  periodic  basis. 

Measurement  1 

Project  and 
Organization 

Both  the  organization  and  the  project  are  responsible  for  ensuring  that  measure¬ 
ments  are  made  and  used  to  determine  the  status  of  the  defect  prevention  activi¬ 
ties. 

Verification  1 

Organization 

The  organization  is  responsible  for  ensuring  that  the  organization’s  activities  for 
defect  prevention  are  reviewed  with  senior  management  on  a  periodic  basis. 

Verification  2 

Project 

The  project  is  responsible  for  ensuring  that  the  software  project’s  activities  for 
defect  prevention  are  reviewed  with  the  project  manager  on  both  a  periodic  and 
event-driven  basis. 

Verification  3 

Project  and 
Organization 

Both  the  organization  and  the  project  are  responsible  for  ensuring  that  the  soft¬ 
ware  quality  assurance  group  reviews  and/or  audits  the  activities  and  work 
products  for  defect  prevention  and  reports  the  results. 
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9.17  Key  Practice  Classification  for  Technology 
Change  Management _ 


Key 

Practice 

Classification 

Notes 

Commitment  1 

Organization 

The  organization  is  responsible  for  ensuring  that  the  organization  follows  a  writ¬ 
ten  policy  for  improving  its  technology  capability. 

Commitment  2 

Organization 

The  organization  is  responsible  for  ensuring  that  senior  management  sponsors 
the  organization’s  activities  for  technology  change  management. 

Commitment  3 

Organization 

The  organization  is  responsible  for  ensuring  that  senior  management  oversees 
the  organization’s  technology  change  management  activities. 

Ability  1 

Organization 

The  organization  is  responsible  for  ensuring  that  a  group  responsible  for  the 
organization’s  technology  change  management  activities  exists. 

Ability  2 

Organization 

The  organization  is  responsible  for  ensuring  that  adequate  resources  and  funding 
are  provided  to  establish  and  staff  a  group  responsible  for  the  organization’s 
technology  change  management  activities. 

Ability  3 

Organization 

The  organization  is  responsible  for  ensuring  that  support  exists  for  collecting 
and  analyzing  data  needed  to  evaluate  technology  changes. 

Ability  4 

Organization 

The  organization  is  responsible  for  ensuring  that  appropriate  data  on  the  soft¬ 
ware  processes  and  software  work  products  are  available  to  support  analyses 
performed  to  evaluate  and  select  technology  changes. 

Ability  5 

Organization 

The  organization  is  responsible  for  ensuring  that  members  of  the  group  respon¬ 
sible  for  the  organization’s  technology  change  management  activities  receive 
required  training  to  perform  these  activities. 

Activity  1 

Organization 

The  organization  is  responsible  for  ensuring  that  the  organization  develops  and 
maintains  a  plan  for  technology  change  management. 

Activity  2 

Organization 

The  organization  is  responsible  for  ensuring  that  the  group  responsible  for  the 
organization’s  technology  change  management  activities  works  with  the  soft¬ 
ware  projects  in  identifying  areas  of  technology  change. 

Activity  3 

Organization 

The  organization  is  responsible  for  ensuring  that  software  managers  and  techni¬ 
cal  staff  are  kept  informed  of  new  technologies. 

Activity  4 

Organization 

The  organization  is  responsible  for  ensuring  that  the  group  responsible  for  the 
organization’s  technology  change  management  systematically  analyzes  the  or¬ 
ganization’s  standard  software  process  to  identify  areas  that  need  or  could  bene¬ 
fit  from  new  technology. 

Activity  5 

Project  and 
Organization 

Both  the  organization  and  the  project  are  responsible  for  ensuring  that  technolo¬ 
gies  are  selected  and  acquired  for  the  organization  and  software  projects  accord¬ 
ing  to  a  documented  procedure. 
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Key 

Practice 

Classification 

Notes 

Activity  6 

Organization 

The  organization  is  responsible  for  ensuring  that  pilot  efforts  for  improving 
technology  are  conducted,  where  appropriate,  before  a  new  technology  is  intro¬ 
duced  into  normal  practice. 

The  organization  is  responsible  for  ensuring  that  appropriate  new  technologies 
are  incorporated  into  the  organization’s  standard  software  process  according  to  a 
documented  procedure. 

Activity  8 

Project  and 
Organization 

Both  the  organization  and  the  project  are  responsible  for  ensuring  that  appropri¬ 
ate  new  technologies  are  incorporated  into  the  projects’  defined  software  proc¬ 
esses  according  to  a  documented  procedure. 

Measurement  1 

Organization 

The  organization  is  responsible  for  ensuring  that  measurements  are  made  and 
used  to  determine  the  status  of  the  organization’s  activities  for  technology 
change  management. 

Verification  1 

Organization 

The  organization  is  responsible  for  ensuring  that  the  organization’s  activities  for 
technology  change  management  are  reviewed  with  senior  management  on  a 
periodic  basis. 

Verification  2 

Project  and 
Organization 

Both  the  organization  and  the  project  are  responsible  for  ensuring  that  the  soft¬ 
ware  quality  assurance  group  reviews  and/or  audits  the  activities  and  work 
products  for  technology  change  management  and  reports  the  results. 
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9.18  Key  Practice  Classification  for  Process  Change 
Management 


Key 

Practice 

Classification 

Notes 

Commitment  1 

Organization 

The  organization  is  responsible  for  ensuring  that  the  organization  follows  a  writ¬ 
ten  policy  for  implementing  software  process  improvements. 

Commitment  2 

Organization 

The  organization  is  responsible  for  ensuring  that  senior  management  sponsors 
the  organization’s  activities  for  software  process  improvement. 

Ability  1 

Project  and 
Organization 

Both  the  organization  and  the  project  are  responsible  for  ensuring  that  adequate 
resources  and  funding  are  provided  for  software  process  improvement  activities. 

Ability  2 

Project  and 
Organization 

Both  the  organization  and  the  project  are  responsible  for  ensuring  that  software 
managers  receive  required  training  in  software  process  improvement. 

Ability  3 

Project  and 
Organization 

Both  the  organization  and  the  project  are  responsible  for  ensuring  that  the  man¬ 
agers  and  technical  staff  of  the  software  engineering  group  and  other  software- 
related  groups  receive  required  training  in  software  process  improvement. 

Ability  4 

Organization 

The  organization  is  responsible  for  ensuring  that  senior  management  receives 
required  training  in  software  process  improvement. 

Activity  1 

Organization 

The  organization  is  responsible  for  ensuring  that  a  software  process  improve¬ 
ment  program  is  established  which  empowers  the  members  of  the  organization 
to  improve  the  processes  of  the  organization. 

Activity  2 

Organization 

The  organization  is  responsible  for  ensuring  that  the  group  responsible  for  the 
organization’s  software  process  activities  (e.g.,  software  engineering  process 
group)  coordinates  the  software  process  improvement  activities. 

Activity  3 

Organization 

The  organization  is  responsible  for  ensuring  that  the  organization  develops  and 
maintains  a  plan  for  software  process  improvement  according  to  a  documented 
procedure. 

Activity  4 

Organization 

The  organization  is  responsible  for  ensuring  that  the  software  process  improve¬ 
ment  activities  are  performed  in  accordance  with  the  software  process  improve¬ 
ment  plan. 

Activity  5 

!  Organization 

The  organization  is  responsible  for  ensuring  that  software  process  improvement 
proposals  are  handled  according  to  a  documented  procedure. 

Activity  6 

Project  and 
Organization 

Both  the  organization  and  the  project  are  responsible  for  ensuring  that  members 
of  the  organization  actively  participate  in  teams  to  develop  software  process 
improvements  for  assigned  process  areas. 

Activity  7 

Project  and 
Organization 

Both  the  organization  and  the  project  are  responsible  for  ensuring  that  where 
appropriate,  the  software  process  improvements  are  installed  on  a  pilot  basis  to 
determine  their  benefits  and  effectiveness  before  they  are  introduced  into  normal 
practice. 
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Activity  8 

Project  and 
Organization 

Both  the  organization  and  the  project  are  responsible  for  ensuring  that  when  the 
decision  is  made  to  transfer  a  software  process  improvement  into  normal  prac¬ 
tice,  the  improvement  is  implemented  according  to  a  documented  procedure. 

Activity  9 

Project  and 
Organization 

Both  the  organization  and  the  project  are  responsible  for  ensuring  that  records  of 
software  process  improvement  activities  are  maintained. 

Activity  10 

Project  and 
Organization 

Both  the  organization  and  the  project  are  responsible  for  ensuring  that  software 
managers  and  technical  staff  receive  feedback  on  the  status  and  results  of  the 
software  process  improvement  activities  on  an  event-driven  basis. 

Measurement  1 

Project  and 
Organization 

Both  the  organization  and  the  project  are  responsible  for  ensuring  that  measure¬ 
ments  are  made  and  used  to  determine  the  status  of  the  software  process  im¬ 
provement  activities. 

Verification  1 

Project  and 
Organization 

Both  the  organization  and  the  project  are  responsible  for  ensuring  that  the  activi¬ 
ties  for  software  process  improvement  are  reviewed  with  senior  management  on 
a  periodic  basis. 

Verification  2 

Project  and 
Organization 

Both  the  organization  and  the  project  are  responsible  for  ensuring  that  the  soft¬ 
ware  quality  assurance  group  reviews  and/or  audits  the  activities  and  work 
products  for  software  process  improvement  and  reports  the  results. 
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10  Conclusion 


Examining  the  relationship  between  the  TSP  and  the  SW-CMM  shows  the  TSP  strongly  sup¬ 
ports  the  key  practices  of  the  SW-CMM,  especially  the  project-level  practices  it  targets. 
When  adopted  across  an  organization,  the  TSP  is  an  instantiation  of  an  effective,  high- 
maturity  process. 


Organizations  choosing  to  use  the  TSP  should  have  no  concerns  about  compatibility  between 
the  TSP  and  the  SW-CMM.  In  fact,  an  organization  can  build  or  tailor  its  SW-CMM  based 
process  improvement  effort  around  the  consistent,  high-maturity  operational  framework  pro¬ 
vided  by  the  TSP. 
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